IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
LAME high bitrate files in l3codeca.ax
menno
post Jan 4 2006, 15:46
Post #1


Nero MPEG4 developer


Group: Developer (Donating)
Posts: 1218
Joined: 11-October 01
From: LA
Member No.: 267



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 smile.gif

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

This post has been edited by menno: Jan 4 2006, 16:21
Go to the top of the page
+Quote Post
Gabriel
post Jan 4 2006, 16:33
Post #2


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



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.
Go to the top of the page
+Quote Post
menno
post Jan 4 2006, 16:43
Post #3


Nero MPEG4 developer


Group: Developer (Donating)
Posts: 1218
Joined: 11-October 01
From: LA
Member No.: 267



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.
Attached File(s)
Attached File  BlackBird_lame3.97.mp3 ( 192.65K ) Number of downloads: 788
Attached File  BlackBird_strict.mp3 ( 192.65K ) Number of downloads: 561
Attached File  BlackBird_fhg.mp3 ( 190.81K ) Number of downloads: 575
 
Go to the top of the page
+Quote Post
robert
post Jan 4 2006, 17:05
Post #4


LAME developer


Group: Developer
Posts: 788
Joined: 22-September 01
Member No.: 5



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?
Go to the top of the page
+Quote Post
menno
post Jan 4 2006, 17:14
Post #5


Nero MPEG4 developer


Group: Developer (Donating)
Posts: 1218
Joined: 11-October 01
From: LA
Member No.: 267



I think LAME just uses too much buffer size, the decoder probably checks for the buffer size limit, which is perfectly fine.
Go to the top of the page
+Quote Post
menno
post Jan 4 2006, 17:27
Post #6


Nero MPEG4 developer


Group: Developer (Donating)
Posts: 1218
Joined: 11-October 01
From: LA
Member No.: 267



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
Go to the top of the page
+Quote Post
menno
post Jan 4 2006, 17:28
Post #7


Nero MPEG4 developer


Group: Developer (Donating)
Posts: 1218
Joined: 11-October 01
From: LA
Member No.: 267



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.
Go to the top of the page
+Quote Post
robert
post Jan 4 2006, 17:30
Post #8


LAME developer


Group: Developer
Posts: 788
Joined: 22-September 01
Member No.: 5



Menno, did you try some more recent Fhg Direct Show filter too, like version 1.9.0.311?
Go to the top of the page
+Quote Post
Gabriel
post Jan 4 2006, 18:06
Post #9


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



QUOTE (menno @ Jan 4 2006, 05:27 PM)
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
*

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.
Go to the top of the page
+Quote Post
menno
post Jan 4 2006, 19:00
Post #10


Nero MPEG4 developer


Group: Developer (Donating)
Posts: 1218
Joined: 11-October 01
From: LA
Member No.: 267



QUOTE (robert @ Jan 4 2006, 05:30 PM)
Menno, did you try some more recent Fhg Direct Show filter too, like version 1.9.0.311?
*


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
Go to the top of the page
+Quote Post
Gabriel
post Jan 5 2006, 09:56
Post #11


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



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.
Go to the top of the page
+Quote Post
menno
post Jan 5 2006, 10:25
Post #12


Nero MPEG4 developer


Group: Developer (Donating)
Posts: 1218
Joined: 11-October 01
From: LA
Member No.: 267



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.
Go to the top of the page
+Quote Post
menno
post Jan 5 2006, 15:13
Post #13


Nero MPEG4 developer


Group: Developer (Donating)
Posts: 1218
Joined: 11-October 01
From: LA
Member No.: 267



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.

This post has been edited by menno: Jan 5 2006, 15:17
Go to the top of the page
+Quote Post
Gabriel
post Jan 5 2006, 17:37
Post #14


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



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?
Go to the top of the page
+Quote Post
menno
post Jan 5 2006, 19:41
Post #15


Nero MPEG4 developer


Group: Developer (Donating)
Posts: 1218
Joined: 11-October 01
From: LA
Member No.: 267



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 blink.gif I expected you knew it laugh.gif
Go to the top of the page
+Quote Post
Gabriel
post Jan 5 2006, 23:16
Post #16


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



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.
Go to the top of the page
+Quote Post
robert
post Feb 15 2010, 13:57
Post #17


LAME developer


Group: Developer
Posts: 788
Joined: 22-September 01
Member No.: 5



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)
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd November 2014 - 23:50