LAME high bitrate files in l3codeca.ax |
LAME high bitrate files in l3codeca.ax |
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 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 |
|
|
|
![]() |
Jan 5 2006, 15:13
Post
#2
|
|
![]() 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 |
|
|
|
menno LAME high bitrate files in l3codeca.ax Jan 4 2006, 15:46
Gabriel We had reports of something going wrong when decod... Jan 4 2006, 16:33
menno I noticed that when I use --strictly-enforce-ISO t... Jan 4 2006, 16:43
robert Your description sounds like a "main data beg... Jan 4 2006, 17:05
menno I think LAME just uses too much buffer size, the d... Jan 4 2006, 17:14
menno Hmm, now I notice that with --strictly-enforce-ISO... Jan 4 2006, 17:27
Gabriel QUOTE (menno @ Jan 4 2006, 05:27 PM)Hmm, now ... Jan 4 2006, 18:06
menno In case of 32 kHz at 320kbps this main_data_begin ... Jan 4 2006, 17:28
robert Menno, did you try some more recent Fhg Direct Sho... Jan 4 2006, 17:30
menno QUOTE (robert @ Jan 4 2006, 05:30 PM)Menno, d... Jan 4 2006, 19:00
Gabriel I intend to find a workaround against this problem... Jan 5 2006, 09:56
menno OK, thanks. Would be great to let us know what the... Jan 5 2006, 10:25
Gabriel QUOTE It seems that the following rule applies for... Jan 5 2006, 17:37
menno Yes, I used bits and bytes through each other, but... Jan 5 2006, 19:41
Gabriel I was hoping for another source than the R.Spersch... Jan 5 2006, 23:16
robert LAME 3.98 is limiting the maximum allowed bits per... Feb 15 2010, 13:57![]() ![]() |
|
Lo-Fi Version | Time is now: 18th June 2013 - 23:05 |