Re: [MP3 ENCODER] CRC problems
Robert Hegemann wrote: [snip] OK, here is the statement out of "MPEG Layer3 / Bitstream Syntax and Decoding" quote If the words (CRC checksum and transmitted values) are not identical, a transmission error has occured in the protected field of the bitstream. To avoid annoying distortions, application of a concealment technique, such as muting of the actual audio frame or repetition of the previous audio frame, is recommended. /quote From my point of view a repetition should not be choosen for the very first frame like the Xing-VBR tagging frame. Because there is nothing to repeat ( no previous frame ) :-) David -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] CRC problems
David Bridson wrote: That seems to be the world upside down. Adapting an encoder in order to fit a non-mp3-compliant player is no good move I think. Best is to contact the mpg123 author? I don't think it's just mpg123 - I have problems playing same file in CL-Amp under BeOS with VBR MP3s and CRC. CL-Amp has both a mpg123-based and an amp-based plugin, if memory serves me right. Maybe you're using the mpg123-based one? -- Magnus Holmgren -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] CRC problems
David Bridson wrote: That seems to be the world upside down. Adapting an encoder in order to fit a non-mp3-compliant player is no good move I think. Best is to contact the mpg123 author? I don't think it's just mpg123 - I have problems playing same file in CL-Amp under BeOS with VBR MP3s and CRC. CL-Amp has both a mpg123-based and an amp-based plugin, if memory serves me right. Maybe you're using the mpg123-based one? Well, since i'm currently surfing, I thought i'd dig out my CD of "Surfin'" and check this out. I've tried both the mpg123 and amp versions (note: the amp plugin is not included with CL-Amp, only as a separate download) of the MP3 plugin. "Surfin'" with CRC plays about 0.5 seconds of squeaks using the mpg123 plugin and the correct length of noise (like an untuned Radio) using the Amp plugin. Without CRC, both plugins play correctly. Is this down to a bug in LAME or a bug in both of the plugins? I'll contact the authors personally if the latter is the case. David -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] CRC problems
If mpg123 needs all frames to have CRC, can the VBR header contain a CRC? Or would the CRC cause problems if it were to be embedded in a VBR header? Shawn -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] CRC problems
Mark Taylor schrieb am Mon, 03 Jul 2000: Thanks Mathew, I just changed VbrTag.c to set the CRC bit for the Xing-VBR tagging frame like the first frame. Now mpg123 works with protected VBR files. Robert This is probabaly the right thing to do, but: Now, the Xing VBR header is actually a corrupt mp3 frame. Before this fix, the Xing header was a valid mp3 frame which would decode to silence. So mpg123 now works, but there might be another decoder, which is not VBR aware (like mpg123) but does actually check the CRC (unlike mpg123). This decoder may now choke on the mp3 file because the first frame is corrupt? Mark OK, here is the statement out of "MPEG Layer3 / Bitstream Syntax and Decoding" quote If the words (CRC checksum and transmitted values) are not identical, a transmission error has occured in the protected field of the bitstream. To avoid annoying distortions, application of a concealment technique, such as muting of the actual audio frame or repetition of the previous audio frame, is recommended. /quote From my point of view a repetition should not be choosen for the very first frame like the Xing-VBR tagging frame. Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] CRC problems
Robert wrote- Now mpg123 works with protected VBR files. Mark wrote- This is probabaly the right thing to do, but: Now, the Xing VBR header is actually a corrupt mp3 frame. Before this fix, the Xing header was a valid mp3frame which would decode to silence. So mpg123 now works, but there might be another decoder, which is not VBR aware (like mpg123) but does actually check the CRC (unlike mpg123). This decoder may now choke on the mp3 file because the first frame is corrupt? Could a checksum be embedded in the header to produce a valid MPEG frame? Would VBR-aware decoders choke on that? Shawn -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
