You can always find the latest version of mp2enc here.
mp2enc is a modified version of the “dist10” sample code that was distributed by the MPEG group to demonstrate audio encoding and decoding. I found it last year when we did the Ben Liebrand DCC Release. I modified it so it can process WAV files with different numbers of sample sizes besides 16 bits, and processes the audio using 32-bit floating point.
But previously, I still had to use my DCCU program to convert the MP1 files to MPP, LVL and TRK files. In the new version, that’s no longer necessary: with a single command, the mp2enc program now generates the files that you can copy straight to your DCC-Studio audio directory to record them onto tape with your DCC-175 with PC-Cable.
This is exciting news for owners of a DCC-175 with PC-Cable: they can now convert WAV files for use with DCC-Studio without the need to use the slow DCC2WAV program that Philips distributed. Converting a file with mp2enc is much faster than DCC2WAV (it only takes a few minutes to convert a song, not an entire day) and the mp2enc converter can handle more formats besides 44.1kHz 16 bit WAV files.
There is of course also still a lot of room for improvement. In the future I hope to make my own version of DCC2WAV, with a graphical user interface, easy editing of titles, creation of compilation tapes, encoding from and decoding to many other audio formats such as MP3 and FLAC, and perhaps even direct recording to DCC with a self-made interface connected to a modern computer through USB.
Hi Jack
Please let us know if this program may be used with some modifications on windows 10
What benefits for those who don’t have this player cable and studio program
Do you have any ideas how to benefit us all with your program thx
The program should be usable with any version of Windows from Windows 98 to Windows 10. It may even work with Windows 95 but I only tested with Windows 98 and Windows 10.
If you don’t have the DCC 175 and PC cable, you can still use it to create MP1 files that are encoded in the same way as DCC recorders do. I guess you could use it to demonstrate how good DCC sounds.
I’m working on a few hardware projects, that will eventually allow you to record files from a computer onto DCC, and play back DCC’s to the computer (for backup purposes) using a USB port and software running under Windows 10. For the DCC 175 it will be possible to plug such a cable into the existing PC cable connector; for other recorders it will be necessary to make modifications. But it should eventually be possible on all recorders.
Hi @Jac
I think I found an issue in the mp2enc (latest version). I stumbled upon a piece of music that is encoded with major artifacts in high frequencies, similar to very low bitrate mp3 (think lower than 96kbps).
The findings are the following:
After a conversion using mp2enc and recording via DCC175 major ‘low bitrate’ artifacts are introduced.
The artifacts are not present when using a standard Philips DCC2WAV utility.
The artifacts are also absent when recording directly to DCC951 via coax input.
This makes mp2enc the major suspect, but I’m not sure how to troubleshoot this. Definitely it breaks the most convenient way to prepare recordings for DCC175. The recording is highly compressed, ‘loud’ with wide frequency range, so it could be difficult for an encoder. But the hardware encoder in DCC951 is apparently not impacted.
I would really appreciate if you could find time to look into this issue. I shared the source track to reproduce here.
I converted the output of mp2enc to a standard MP1 file using the DCCU utility. The spectral analysis shows that all frequencies above 9khz are severely distorted.
We are aware of problems in the mp2enc encoder, and I can no longer recommend it. mp2enc is based on the “dist10” encoder but it it was modified by the original authors to use 16 bit floating point instead of 32 bit. I tried to undo the modifications and the encoding sounded good to me, but we’ve had reports from DCC users with much better ears than mine, and they also heard bad distortions. So either I made a mistake restoring the original code, or there are some other problems in the code that I didn’t recognize.
Instead of mp2enc, we now use NCH Switch at the DCC Museum. It’s an excellent audio converter with MP1 support (*). The “golden ears” users who reported problems with mp2enc-encoded files reported that there are no distortion problems with NCH encoded files. We have a commercial license to encode our own DCC releases but I think the program is available for free for personal use (look for a separate link on their download page to download the free version).
The MP1 files that are produced with NCH Switch (or by any other program) can be converted to PASC using the DCCU utility, however, unfortunately, DCCU generates a dummy .LVL file that doesn’t have actual audio levels, so you can’t see the waveform in DCC-Studio unless you record the file to tape and then read it back into the computer. I hope to find some time to fix this soon (it basically requires DCCU to have a partial MP1 decoder). This is one of my many ongoing DCC-related projects that I keep being unable to get to.
Interesting! How did you do this, exactly? As far as I know, TwoLame can only encode to MP2 or MP3. In fact I’ve created a project (working title “OneLame”) to add MP1 encoding to TwoLame. It’s based on “dist10” just like many other encoders/decoders but the MP1 encoder was removed and I want to add it back.
===Jac
(*) NCH also makes an excellent audio editing program called WavePad, which is available for Windows, Android and Apple. It’s not free but well worth the price. It loads from, and saves to MP1 as well as many other file formats, and can take the encoding into account when you make edits (so if you cut a sound file into two fragments, it can force you to cut between two MPEG frames, so you won’t have any silence if you play the files together)
Here is an MP1 version of your WAV file, encoded at 384 kbps with the NCH software. 1.mp1 (8.2 MB)
Thank you for your response @Jac
In my previous experiments I’ve obviously mixed MP1 and MP2 encoders. Twolame of course produces an MP2 file, so it is not applicable.
These findings motivate me to try to analyse the existing software encoders and compare them to the ‘ground truth’, which is the hardware implementation in a DCC recorder. Allow me to share some quick findings.
We definitely rule out mp2enc, since it ‘eats’ everything above 9khz (10khz with a 48khz input).
At the moment I could find two software encoders: NCH Switch, that you recommended, and the command-line tool from the mjpegtools package, also known as mp2enc. Both encoders do not demonstrate any weird behavior when analyzing the spectrum of a real song. From top to bottom: source WAV file, NCH Switch, mp2enc from mjpegtools:
Some content is removed, but there is nothing extraordinary.
I tried to compare these encoders in a different way. In Room EQ Wizard I generated a multi-tone signal that spans the entire audible range, from 20hz to 20khz. For lossy compression algorithms this is the worst-case scenario: lots of audible data across the entire frequency range. Analyzing the artifacts introduced by compression does not offer judgement of the actual sound, but allows to compare the ‘raw’ performance of different codecs. To start with, here’s the source file:
31 tones from 20 to 20000 Hz. Then I encoded this test signal using the NCH tool, and also recorded the same signal to DCC951 and extracted the file via DCC170. Therefore, we are operating in the digital domain only, and compare only the performance of lossy compression. Here’s the result:
Green is NCH, blue is DCC951 hardware encoder. Although in reality these differences may be inaudible, I suggest that (a) NCH encoder is noticeably different from the one provided by the DCC951 and (b) DCC951 hardware encoder offers higher fidelity. Not only the noise floor is lower, DCC951 also preserved the highest 20000Hz tone, while the NCH encoder removed it.
Finally, I added the mp2enc from mjpegtools, in red:
The downside of this encoder is that it does not work with 24bit audio files, only 16 bit. It is also noisier, distorts lower frequencies a bit and there is a certain rollof in the higher frequencies (starting from 5khz), that does not exist in other two tests.
Takeaways:
This comparison suggests that the hardware encoder in DCC951 is still superior to the tested software options.
Among the two software options tested, NCH is my preference. It supports 24bit sources (however, I need to test if it retains this extra dynamic range). The downside is that it is not a command line tool. mp2enc was convenient in this regard, as it allowed me to create a set of tracks for DCC Studio in one go, from Foobar2000.
Are there any other software encoders that we can evaluate?
(blue - DCC951, red - DCC2WAV). The result is virtually identical to DCC951. I wonder if it is possible to reverse-engineer the code of DCC2WAV and adapt it to modern PCs, with 24 bit support
I suspect that the hardware encoder and DCC2WAV use the same reference encoder (probably identical to “dist10” or very close). Newer software may use different psycho-acoustic models that were created after 1992. mp2enc has “model 2” and Lame has different models too. My ears aren’t good enough to hear the difference and I don’t know how the newer models are different.
As you may know, all compliant MP1 files can be decoded with the standard decoder and the decoder is always the same; it’s basically a multi-frequency synthesizer.
The original “dist10” encoder might be interesting to compare with. I suspect that’s what other tools use too, though.
Possible? Definitely! And with tools like Ghidra it might not even be too hard.
But it’s probably easier to start with existing source code like TwoLame and add the MP1 encoder back to the encode.c module. TwoLAME claims to be a drop-in replacement for LAME and that’s used by pretty much all audio conversion tools that are out there. And it uses libsndfile, so it supports pretty much any audio file that you can throw at it.
I sourced an old encoder that appears to be based on dist10 (from here). It allows to select one of two psychoacoustic models. Model 2 in multitone test is virtually identical to NCH:
Model 1 acts differently, with less noise in the lower frequency range, and it also retains the 20khz tone. But they are both different from the DCC951 (or DCC2WAV) output:
Finally, I checked twolame. Yes, it is MP2, but you mentioned that it could become a source of the new DCC encoder. My tests show that something strange is going on with this encoder:
Not only it exhibits the most noise, but it also for some reason reduces the output by 5dB, which is not great.
Personally, I see two options for a new DCC Studio workflow:
Use the original DCC2WAV utility, in a virtual 32bit machine, or run natively on a laptop that I use to manage DCC Studio (it’s a Pentium III, so not super slow). Suitable for 16bit sources, and is so far the closest alternative to a hardware encoder.
Use NCH encoder for 24 bit sources. On this I have doubts. Should I decide to record a hi-res audio material to DCC, in these circumstances I’d rather record to DCC951 directly, using its hardware encoder.
The original dist10 didn’t have a choice of models. I think the original model is now called “Model 0” or maybe “Model 1”. If you used a model that doesn’t correspond to the original one that dist10 used, that would explain the difference between SoloH and DCC951/DCC2WAV.
I’m sorry, but I find that difficult to believe. In 1992 there was only one encoder. I don’t think Philips went through the trouble of creating a PASC encoder in both hardware and software, that was different from the standard that they created. I think maybe you’re comparing DCC951/DCC2WAV with a modified version of dist10 that uses a different model.
Another possibility is that maybe my DCCU tool introduced artifacts because you’re using it at 44100 Hz sample rate. A 44.1 kHz PASC or MP1 stream contains extra slots of data on 25 out of 49 frames, but in PASC those extra slots cannot contain data whereas in MP1, they can and do. DCCU zeroes out the padding slots when converting from MP1 to MPP which is technically not the right thing to do. In mp2enc I modified the encoder so that in PASC mode, it always encodes 104 frames instead of sometimes 104, sometimes 105. But in DCCU I can’t do that because the input data is already encoded.
I’d be happy to investigate further. Can you point me to a known reference implementation of dist10?
DCCU was not used in purely software measurements: after conversion to MP1 with a given converter, I decompressed it back to WAV and sent to Room EQ Wizard for measurements. However, it was used to convert DCC951 and DCC2WAV samples back to MP1. So it’s fair to suspect that DCCU somehow altered the graph. I will try to capture these samples without using DCCU, probably via optical out of a DCC951.
If you used DCCU to convert PASC (.MPP) to MP1, it didn’t modify the data at all. An MPP file basically contains a word that indicates the sample frequency in kHz, followed by PASC frames. When 44.1 kHz is used, the word contains the value 44 (0x002C) and the PASC frames are padded to 420 bytes per frame so that it’s easier for the DCC-Studio program to locate a particular frame number in a file. All that DCCU does is remove the word at the beginning and copy all the frames. It removes the padding for 44.1 kHz files. PASC doesn’t use the extra slot in 105-slot frames in a 44.1 kHz stream but PASC data is otherwise perfectly compatible with MP1 so DCCU doesn’t need to touch the data when converting from PASC to MP1.
