Howdy Steve,
In case Mark's reply didn't adequately solve your problem:
> I'd like to know your point of view on the "Free format" that
> lame generates.
> I've created a free format file with 'lame --freeformat -b 62
> file.au". I'm using lame 3.86beta on Win32 compiled locally
> using MinGW32 with Libsndfile and full speed optimization
> (all I found usefull in the GCC doc). And it usually works fine.
>
> But with free format, it sometimes generate half frames. The
> file seems to have the following characteristics :
> MPEG_VERSION MPEG_2
> MPEG_LAYER LAYER_III
> PROT_BIT 0
> BIT_RATE 1
> SAMPLE_FREQ 22050
> SAMPLES_PER_FRAME 1152
> PAD_BIT 0
> PRIV_BIT 0
> CHANNEL JOINT_STEREO
> MODE_EXTENSION Intensity OFF / MS ON
> ID3V2 0
> FRAME_LENGTH 405
> COPYRIGHT 0
> ORIGINAL 1
> EMPHASIS NONE
> CHECK_STATE 1
> BIN_STRING 11111111111100110000000001100100
>
> BIT_RATE = 1 means free format.
This seems kinda confusing -- why use 1 to indicate free when MPEG uses 0?
> I've checked the file in hexadecimal, and sometimes I get
> frame header at 202 bytes from the previous instead of 405.
> So I was wondering if this is not a bug of lame or if the
> free format allow this (but I don't think so).
>
> The other possibility is that the real frame size is 202
> bytes, but then would some of the frames would be separated
> by 405 bytes ?
Doing the math:
(576 samp/gr * 1 gr/fr * 62000 bps)/(8 bit/byte * 22050 samp/s) = 202.4
byte/fr
layer-III MPEG-2 bitrate conversion samp freq
Given that this is non-integral, padding will sometimes occur. When the
padding bit is cleared, the frame size will be 202, and when it is set, it
will be 203. Thus, I surmise that there are no 405 byte frames - you just
aren't tracking syncs correctly. Are you factoring in the padding bit?
Hope that helps,
Alex
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
