IPB

Welcome Guest ( Log In | Register )

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
 
Start new topic
Replies
menno
post 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
Go to the top of the page
+Quote Post

Posts in this topic


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: 28th December 2014 - 00:05