I have no idea about what the “Adaptive Encoding” option does, so at least if you’re going to research that, you’re not reinventing the wheel 
. I suspect that that may enable Joint Stereo encoding or something. If you try encoding a sample with and without the flag, a quick inspection of the PASC header (the first 32 bits of each frame in the .MPP file), will probably tell you what difference it makes.
The DCC-Studio program works with:
- .TRK files which are a representation (in ASCII) of which PASC files are used, combined with frame numbers (each frame is 420 bytes), markers, volume and equalization settings, etc. I never bothered to figure out the exact format but a .TRK file for a single PASC file, should be easy to reproduce. DCC-Studio can generate .TRK files if you tell it to search the drive for orphan PASC files.
- .LVL files are a representation of the levels of a sound file. I haven’t ever looked at them so I don’t know exactly what’s in there but I suspect that the program calculates an average or maximum volume of each MPEG frame by looking at the scale values, and storing the resulting “volume” for each frame as a byte or nibble for each channel or something. If I remember correctly, DCC-Studio automatically generates the .LVL file if you open a .TRK file for which there is no .LVL file.
- .MPP files contain the actual audio data. They start with a word that contains $2C $00 (*), following by MPEG/PASC frames. The frames are described in ISO/IEC 11172-3 but the language is difficult to follow. I learned a lot from the document at this location which describes a decoder implemented in VHDL for an FPGA. However, unfortunately, the actual source code is not included and seems to be not available on the Internet.
As I already mentioned, I did some research a few weeks ago to find an MP1 encoder that could encode at 48 kHz. I didn’t try to convert an output file to DCC-Studio format because I suspected that the bit stream that came out of that encoder was wrong because it used a different frame size than the 420 bytes that I was used to seeing.
But now I’ve spent some time reading the ISO/IEC standard, and the document linked above, I realize I was wrong: the 384 byte frame size for 48kHz was correct. So I’m going to try and find some time to see if I can get some 48kHz encoded MP1 audio onto my Windows 98 laptop and see if DCC-Studio can work with it. I have a funny feeling that it can. In fact, I think that 48kHz as well as 32kHz will work fine from any MP1 encoder (if concatenated after the required 2-byte DCC-Studio header)
I remember in the 1990s I tried to find out if there was a MPEG-1 encoder that could be made to generate .MPP files for DCC-Studio. I knew that the problem with MP1 decoders was that they couldn’t handle the padding bit and I knew how to work around that. But I had no idea why the padding bit was necessary (I found out around 2003 when I first had a look at the IEC/ISO standard) and I up until now, I didn’t know when and how an encoder should produce a shorter frame with a padding bit. The answer is:
For 44.1kHz encoded MP1/PASC, Every regular frame is followed by a padded frame, except for every 49th frame in a sequence.
I now suspect that many MP1 encoders get this wrong (or simply don’t care), which makes the MPEG data unusable for DCC or DCC-Studio. Everything else in the encoding for MPEG 1 Layer 1 is the same as, or compatible with DCC. And that’s probably why I could never get any other MPEG 1 Layer 1 encoders to generate a usable file for DCC-Studio, but my memory is vague – I don’t even know what happens if you try.
The problem is caused by this: Each frame in the MPEG/PASC data contains a number of “slots” where each slot is 32 bits. The number of slots per frame is fixed at 12 x (bit rate / sample rate). For 44.1 kHz this results in a non-integer result, so that’s where padding is used.
- For 32kHz there are 12 * (384000 / 32000) = 12 * 12 = 144 slots, i.e. 576 bytes per frame. Every frame represents exactly 12ms of audio.
- For 48kHz there are 12 * (384000 / 48000) = 12 * 8 = 96 slots = 384 bytes per frame. Every frame represents exactly 8ms of audio.
- For 44.1kHz the formula results in 12 * (384000 / 44100) = 12 * 8.707… = 104.48… slots.
The calculated number of slots for 44.1kHz is actually 104 + (24/49). That basically means that for any sequence of 49 frames of Layer 1 data, 25 frames should have 104 slots (416 bytes) and 24 frames should have 105 slots (420 bytes) so that the average over time evens out and the time per frame is 8.7ms.
===Jac
(*) EDIT: I haven’t verified this at the time of this writing but I now suspect that the $2C $00 header indicates the sample rate used in the file: $2C equals 44 in decimal. I never used DCC-Studio with 48kHz or 32kHz sound sources but I would not be surprised if the first byte changes to $20 (32 decimal) for 32 kHz and $30 (48 decimal) for 48kHz.