For MP1, each frame is basically Header - Allocations - Scalefactors - Samples.
For MP2, each frame is Header - Scalefactor Selection Info - Scalefactors - Sample Codes - Samples.
I still don’t know the standards thoroughly but it may be possible to make an MP1 codec out of an MP2 codec. by leaving out the processing of the scale factor selection info and scale factor codes. But of course it would be easier to start with a working MP1 encoder.
The difference between MP1 and PASC is: nothing. My discovery yesterday basically means that, quite likely, the extra zeroes between frames in .MPP files are an optimization in the DCC-Studio program to make it easier to seek to a particular frame in a file, not a difference between PASC and MP1, and not a misinterpretation of the MPEG standard by codec writers.
MP1 encoders/decoders already exist, possibly with varying speed and quality. I think it’s possible to make improvements, e.g. by using integer-only encoding/decoding for speed, 32 bit internal operations for accuracy, and the possibility of using alternate Psycho-Acoustic Models for the encoding. Even if you understand the standard very well, I think that might still be quite a bit of work. It might help to have some knowledge about DSP or MMX or GPU programming because a lot of the processing can be done in parallel (that document I linked to earlier, about the FPGA implementation of an MP1 decoder, would help with parallelization).
However: Making an MPP file out of an MP1 file, or vice versa, is trivial. Modifying an existing MP1 encoder to generate an MPP file instead of an MP1 file or modifying an MP1 decoder or player to accept an MPP file as input, should be very easy.
If you want to create a replacement for DCC2WAV, that would not be very useful I think. DCC2WAV can only convert from 44.1 stereo PCM WAV to .MPP/.TRK/.LVL, or vice versa, as far as I know. Sure, a fast version of that program (and a version that works on other operating systems besides DOS) would be useful, but why stop there?
Instead, I think it would be useful to start with a library or application that already exists, and can convert many different formats to many different other formats, and/or can play many different formats. After going through the learning curve of understanding how the existing program works, adding functionality to convert from/to .MPP/.TRK/.LVL should be trivial if such a program already supports MP1.
The TwoLame software doesn’t support MP1. Adding MP1 support should be possible because as I understand MP2 is a more sophisticated version of MP1 (I may be wrong). Whether the authors are interested in an MP1/PASC feature, is another question. Maybe CDex (which already supports MP1) is a better idea after all. It would only be necessary to change the decoder to skip the header and the extra slots in .MPP files, and the encoder to insert those slots into encoded MPP files.
===Jac