Re: [MP3 ENCODER] Free Format problem

[Steve Lhomme]

Thanx, that was the info I was missing.

Now I get the track length on every example I had (some with free format too, some 
with different sampling freq, some with different bit rates)

- Original Message - 
From: "Mark Taylor" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, August 21, 2000 6:25 PM
Subject: Re: [MP3 ENCODER] Free Format problem


 If sample_freq  32khz, samples per frame = 576 (not 1152)!
 
 This the the so-called 'LSF' extension of MPEG: 
 
 32khz - 48khz:   MPEG1 Layer 3  1152 samples per frame
 16khz - 24khz:   MPEG2 layer 3   576 samples per frame
 8khz  - 12khz:   MPEG2.5 layer 3 576 samples per frame.


--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] Free Format problem

[Steve Lhomme]

  BIT_RATE = 1 means free format.
 
 This seems kinda confusing -- why use 1 to indicate free when MPEG uses 0?

0 is for 'reserved' (I'm not responsible of this part of the code).
 
  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-IIIMPEG-2 bitrateconversionsamp freq

You're right ! The correct frame length was 205. I was looking for another same frame 
header the wrong way (I forgot the PAD_BIT could be different).

 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?

--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )