The difference between PASC and MPEG 1 Layer 1

[Jac]

After I read some documentation about MPEG-1 Layer 1 again this week, I realized that I misunderstood some arguably important things about the difference between PASC and MPEG 1 Layer 1. So let me elaborate on that.

The MPEG standard (IEC/ISO 11172-3) defines that each frame of MPEG-1 Layer 1 (which I shall refer to as MP1) audio shall have the following number of slots:

N = 12 * B / S

Where:

• N is the number of slots per frame; one slot is 32 bits
• B is the bit rate of the encoded stream; for DCC this is 384000
• S is the sample rate of the audio; DCC supports 32000, 44100 and 48000.

So, for 32 kHz, each frame has 12 * 384000 / 32000 = 144 slots = 576 bytes. Each frame represents 12 ms of audio (144 * 32 / 384000).

For 48 kHz, each frame has 12 * 384000 / 48000 = 96 slots = 384 bytes. Each frame represents 8 ms of audio (96 * 32 / 384000).

For 44.1 kHz, the calculation results in a non-integer: 12 * 384000 / 44100 = 104.489795918 according to my calculator. The actual accurate result is 104 + 24/49. That means that:

When a 44.1 khz audio stream is encoded in MP1, the encoder must write frames that alternate between 104 and 105 slots (416 or 420 bytes), but every 49 frames, a 104-slot frame would be followed by another 104 slot frame, after which the alternation would continue.

So the frame lengths are [0]104 [1]105 [2]104 [3]105 … [46]104 [47]105 [48]104 [49]104 [50]105 [51]104…

The MP1 standard defines the padding bit in the header of an MP1 frame that indicates that the frame “contains an additional slot to adjust the mean bitrate to the sampling frequency”.

This bit is not well documented and unless you read and understand the standard document, it’s difficult to understand.

As it turns out, I interpreted it wrong.

Around 1996, I was on the DCC-L email discussion list (remember those?) and someone asked about whether it would be possible to convert the compressed data format on DCC tapes to something that could be played on e.g. a PC. I don’t remember the exact phrasing of the question but until then, I thought Philips had invented some sort of compression system that would be closed-source forever. But someone on DCC-L who worked for Philips said that PASC was basically the same as MPEG Layer 1. That was a bombshell!

Someone else had figured out (or already knew) that the .MPP audio files of the DCC-Studio program could be converted to MP1 files that could be played or converted with an MP1 decoder. The program was written in Turbo Pascal and would read one frame at a time, check the bit in the header, reverse the bit if necessary and write the frame without the extra 32 zero-bits to an output file. I didn’t have a website of my own at that time, but someone else put it on their website so that anyone could download it and use it.

Unfortunately that website went offline sometime between 1997 and 2003. And I didn’t have a copy of that program. But in 2003 I came across the ISO/IEC 11172-3 standard and read it for the first time. I didn’t understand much of it in 2003. But I did finally find out what that mysterious bit in the header was for.

What I got wrong at that time was that I thought that the bit in the header meant that the frame had an extra slot of zeroes (if the bit was set to zero) so that all frames would end up being 420 bytes and the tape speed for DCC could be clocked from the data speed. After all, that’s what I had observed with the .MPP files that were used by DCC-Studio. But now I’m pretty sure it’s not true.

The bit in the header indicates that the frame has an extra slot with data at the end (if the bit is set to one), and this only happens for 24 out of every 49 frames. I’m pretty sure the extra zero-bytes are inserted into the .MPP file by the DCC-Studio program to make all the frames in the file 420 bytes and make it easy to seek to a particular frame. As far as I know, on the tape, PASC is encoded in the exact same way as MP1.

I’ll have to verify this with a logic analyzer, and if I’m right, I guess I’ll have to update some Wikipedia pages, and some other documentation…

===Jac

[Max]

@Jac

Someone else had figured out (or already knew) that the .MPP audio files of the DCC-Studio program could be converted to MP1 files that could be played or converted with an MP1 decoder. The program was written in Turbo Pascal and would read one frame at a time, check the bit in the header, reverse the bit if necessary and write the frame without the extra 32 zero-bits to an output file. I didn’t have a website of my own at that time, but someone else put it on their website so that anyone could download it and use it.

Does not sound too complicated. Would you like to do it, or should I?

[Jac]

@Max

Does not sound too complicated. Would you like to do it, or should I?

I already wrote a program that converts an MPP file to MP1. See Home/Software/JacGoudsmit | DigitalCompactCassette.github.io

I don’t have a program to convert MP1 to MPP yet but that should be easy too.

I expect that I’ll eventually get to this, and I’ll also modify an existing MP1 decoder/encoder to use/generate MPP files. If you want to take a stab at it, be my guest. I think you already have access to the CDex and twolame repos in the DigitalCompactCassette group on Github; if not, let me know or use a pull request.

===Jac

[Max]

Sorry, did not know that. We should make the removal of the padding bit optional, I suspect that mp2enc does add some of it or does something else. I am currently A/B testing and comparing the DCC2WAV → DCCCONV and mp2enc of the same origin wav, they definetely have some differences, but I am not sure what exactly.

Would you like to do the mp1 → mpp or should I?

I may have found some bugs in the display of files already.

[Jac]

@Max

Would you like to do the mp1 → mpp or should I?

I will eventually adapt DCCCONV to do MP1->MPP as well as MPP->MP1 (and I’ll work on other sample frequencies besides 44.1kHz too). But it may take a while before I get to it. If you write it first, your version will be used. As I implied before: I welcome any reasonable pull request and you should have write access to CDex and twolame in the DigitalCompactCassette group on Github. That means you’re free to change things if you want and when you want. You don’t have to ask me if I want to do it first

I don’t see myself writing my own MP1 encoder/decoder any time soon. that’s already been done by many others and I’d rather work on things that haven’t been done yet.

===Jac

EDIT: Click here for information about the DCCU tool that converts between MPP and MP1 and vice versa.

[Max]

I found a definitive answer to your question:

PASC has a specified decoder and encoder compared to just the decoder, in MPEG 1 Audio Layer 1 the encoder is just an example. I think you will have to send a modified mp1 to @drdcc to see if anything breaks. Because of this cascaded decoding and encoding is supposed to degrade less than other formats,

PASC does also not use the optional CRC error correction, because the recorders already do that on a data level. But I don’t think anyone else does this.

Transcoding up to mp2 and/or back is supposed to be possible in better quality because the frames stay intact. To be honest, this contradicts the claim of being robust, we will have to test.

[Jac]

Sorry to revive this thread, but I just discovered something subtle but important:

• The DCC System Description says: “The padding bit (bit 22) indicates whether the current frame contains a ‘dummy’ slot”.
• The ISO-11172-3 standard says: “If this bit equals ‘1’ the frame contains an additional slot to adjust the mean bitrate to the
  sampling frequency, otherwise this bit will be ‘0’”.

The difference is subtle but important: The PASC standard defines the padding slots as “dummy”, i.e. they are ignored and apparently always filled with zero, whereas the MPEG audio standard implies that the slot is used to encode data.

I discovered this difference when I was encoding the files for the upcoming “Real Mother For Ya” album release by Johnny ‘Guitar’ Watson and the DCC Museum. The files from the mp2enc encoder caused horrible hiccupping when converted to DCC-Studio format.

I found out that the files that mp2enc generates, all started with 23 (not 24) pairs of unpadded and padded frames, followed by an extra unpadded frame. The DCC specification says the extra unpadded frame is at the end of a group of 49 packets, so I modified the code even though it shouldn’t make a difference how the unpadded and padded frames are distributed (as long as every 24 out of 49 frames are padded).

So now the files from mp2enc started with 24 pairs of unpadded and padded frames, followed by an extra unpadded frame. And the files played okay, but when I used the scrubber in DCC-Studio to start playing from elsewhere in the file, it still messed up the sound!

Then I had a look at some files from DCC-Studio that I know were recorded from an audio CD using either my DCC-730 or my DCC-175, and I compared them with the file generated by mp2enc. In the DCC-native files, the padding bytes were all zero, and in the mp2enc-encoded files, the bytes were all zero.

So it looks like the PASC encoder chips in DCC recorders (or at least the one in the DCC-175) can play MP1 encoded files with data in the padding bytes, plays the files just fine under some circumstances, but really expects those padding bytes to be zero.

I’ll modify the mp2enc encoder later today to make a “PASC mode” which always encodes only 104 slots of every frame in a 44.1kHz stream, even the padded ones.

===Jac