Hi,
I found a problem with LAME high bitrate CBR files (256 kbps and 320 kbps only it seems) when playing them back using l3codecx.ax. It happens only when the decoder decodes a frame of silence (where LAME produces some version messages and 0x55 fillup bytes to keep up to a constant bitrate). After that the decoder will not produce sound anymore, but only silence. It also happens when such a silence frame occurs somewhere in the middle of a file.
EDIT: It's not a problem with the ACM filter it's a problem with the DirectShow filter for MP3 decoding that comes with Windows. The version info says: MPEG Layer 3 Audio Decoder version 1.5 (build 50). This filter is called l3codecx.ax, not l3codeca.acm
Is this a known problem? Any easy solutions for it? FhG encoded high bitrate CBR files don't have this problem (it fills up with 0xFF and no version messages).
Menno
We had reports of something going wrong when decoding our high bitrate files in directShow.
However, it was hard to track down as we only knew that something was going wrong with some files and some directshow decoders.
This is at least a precise description of the problem, many thanks.
Right now we have no solution, as we just became aware of the real problem.
Investigation is needed to check if the decoder is chocking on the version string, encoder string, or something else.
If would be very helpfull if you could post a sample file, so other people could try it with different filter versions and report results.
I noticed that when I use --strictly-enforce-ISO the files decode fine... so the problem must somewhere in what is enabled or disabled when not using that option.
Your description sounds like a "main data begin" backpointer problem. Maybe the l3codecx.ax filter has a too small buffer and cannot handle bitreservoir plus data of the actual frame?
I think LAME just uses too much buffer size, the decoder probably checks for the buffer size limit, which is perfectly fine.
Hmm, now I notice that with --strictly-enforce-ISO a 32kHz file with 320kbps does not decode with this decoder (unless I skip the silence). This 7680 bit frame_size limit, is it the limit for the frame (header to header), for a granule or for the main_data? I don't really understand much of what is written about it in the specification.
Menno
In case of 32 kHz at 320kbps this main_data_begin pointer should always be 0 I think, which it is in LAME, whether I use the strict option or not.
Menno, did you try some more recent Fhg Direct Show filter too, like version 1.9.0.311?
Hmm, now I notice that with --strictly-enforce-ISO a 32kHz file with 320kbps does not decode with this decoder (unless I skip the silence). This 7680 bit frame_size limit, is it the limit for the frame (header to header), for a granule or for the main_data? I don't really understand much of what is written about it in the specification.
Menno
[a href="index.php?act=findpost&pid=354544"][{POST_SNAPBACK}][/a]
This limit is supposed to be the limit of main_data size. However, the standard is written in a way that we are unsure if the 7680 value is an example related to 48kHz or a strict value for all sampling rate.
FhG encoders are not enforcing the 7680 value, so the truth related to the max value must be somewhere else than in the ISO doc.
Menno, did you try some more recent Fhg Direct Show filter too, like version 1.9.0.311?
[a href="index.php?act=findpost&pid=354547"][{POST_SNAPBACK}][/a]
Well, it only matters to me that it doesn't work with this version, because Nero falls back to this codec when Nero is installed without any mp3 codec. So we have to find some way that the files will work with this decoder.
I'll try to get some info from someone at FhG.
Menno
I intend to find a workaround against this problem.
Now that we have an accurate description, it will be easier.
note: 3.97b1 is probably working fine with this decoder.
OK, thanks. Would be great to let us know what the workaround would be, so that we can somehow build a detector that would detect frames that can not be decoded.
It seems that the following rule applies for the main_data_begin (mdb):
max_mdb = max( 0, min( mdb_limit, 7680 - bitstream_frame_length))
with mdb_limit = 2^9 for MPEG1
This max_mdb is 125 bytes for 256 kbps at 44.1kHz, LAME in strict-ISO mode already uses 210 for mdb, that I checked, but this file decodes fine. (in non ISO mode the mdb gets much higher).
So apparantly this decoder does not strictly apply this rule. So I thought maybe they use some power of 2 sized buffer (ringbuffer with fast AND accessing), 1kB probably, because 835 (framesize) - 36 (header+sideinfo) + 210 (mdb) (=1009) is just smaller than that. So in my theory LAME should be able to go up to 225 for mdb (at 256 kbps, 44.1 kHz) to still be decodable by this decoder.
Another rule is that a granule can never be bigger than 7680 bits, but this only applies for framesizes bigger than 7680 bits (so 320 kbps only at 44.1 kHz).
EDIT: And I just checked the mdb of the FhG encoder I compared with and it uses exactly 125 bytes for mdb as a maximum.
It seems that the following rule applies for the main_data_begin (mdb):
max_mdb = max( 0, min( mdb_limit, 7680 - bitstream_frame_length))
with mdb_limit = 2^9 for MPEG1
Sorry, but you are mixing bits and bytes there.
The 7680 value is in bits, while the mdb is in bytes.
However, there is a possibility that there is a limit on mdb value. Where did you get this idea from?
Yes, I used bits and bytes through each other, but as far as I can see all values I mention are correct. This formula comes from a document by Ralph Sperschneider and I found it on mp3-tech.org I expected you knew it
I was hoping for another source than the R.Sperschneider document. The one I have on mp3-tech includes some unclear points, so I was hoping for clarifications through another source.
LAME 3.98 is limiting the maximum allowed bits per frame to circumvent the FhG decoding problem. I found this to be not satisfying. With 3.99 alpha 2 LAME doesn't use this hack anymore. menno, could you be so nice and try this version and look out for decoding problems with the FhG decoder? For the problem sample I have, it seems to be working. (Black Bird)