HydrogenAudio

Lossy Audio Compression => MP3 => MP3 - Tech => Topic started by: menno on 2006-01-04 14:46:37

Title: LAME high bitrate files in l3codeca.ax
Post by: menno on 2006-01-04 14:46:37
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
Title: LAME high bitrate files in l3codeca.ax
Post by: Gabriel on 2006-01-04 15:33:57
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.
Title: LAME high bitrate files in l3codeca.ax
Post by: menno on 2006-01-04 15:43:27
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.
Title: LAME high bitrate files in l3codeca.ax
Post by: robert on 2006-01-04 16:05:48
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?
Title: LAME high bitrate files in l3codeca.ax
Post by: menno on 2006-01-04 16:14:07
I think LAME just uses too much buffer size, the decoder probably checks for the buffer size limit, which is perfectly fine.
Title: LAME high bitrate files in l3codeca.ax
Post by: menno on 2006-01-04 16:27:13
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
Title: LAME high bitrate files in l3codeca.ax
Post by: menno on 2006-01-04 16:28:56
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.
Title: LAME high bitrate files in l3codeca.ax
Post by: robert on 2006-01-04 16:30:22
Menno, did you try some more recent Fhg Direct Show filter too, like version 1.9.0.311?
Title: LAME high bitrate files in l3codeca.ax
Post by: Gabriel on 2006-01-04 17:06:25
Quote
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.
Title: LAME high bitrate files in l3codeca.ax
Post by: menno on 2006-01-04 18:00:08
Quote
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
Title: LAME high bitrate files in l3codeca.ax
Post by: Gabriel on 2006-01-05 08:56:39
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.
Title: LAME high bitrate files in l3codeca.ax
Post by: menno on 2006-01-05 09:25:07
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.
Title: LAME high bitrate files in l3codeca.ax
Post by: menno on 2006-01-05 14:13:09
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.
Title: LAME high bitrate files in l3codeca.ax
Post by: Gabriel on 2006-01-05 16:37:33
Quote
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?
Title: LAME high bitrate files in l3codeca.ax
Post by: menno on 2006-01-05 18:41:12
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
Title: LAME high bitrate files in l3codeca.ax
Post by: Gabriel on 2006-01-05 22:16:30
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.
Title: LAME high bitrate files in l3codeca.ax
Post by: robert on 2010-02-15 12:57:58
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)