I'm using new Win32 compiles from Dmitry. There appears to be a bug in LAME
3.84 CVS where it won't start encoding some WAV files (LAME -q1 file.wav). It
just sits there doing nothing probably in an infinite loop. -q2 works fine. I
managed to encode an entire album but for another album there
Hello,
After a few dozen of those frequency analysis graphs, I noticed
something that made me curious: The 16+kHz region of a VBR encoded
file vs the 256S cbr.
http://users.belgacom.net/gc247244/extra/why_oh_why.png [8KB]
is a _very_ striking illustration, and I started thinking about this.
Hello,
*Perhaps* you'll find it useful...
http://www.cmis.csiro.au/dmis/maaate/
(and for people who are very new to MP3 :
http://www.cmis.csiro.au/dmis/maaate/layer3.txt
Now, I can understand more posts than before ! ;-) )
Also, there's a program named mp3_check that you can download after a
Okay, I isolated a 3 second clip from that track:
http://home.hiwaay.net/~stephena/near-silence.wav
http://home.hiwaay.net/~stephena/near-silence.mp3
I was wrong, earlier lame's encode the same way as the newer
alphas. I am still surprised however at the bitrate selected for this
piece. VBR
Hello,
After a few dozen of those frequency analysis graphs, I noticed
something that made me curious: The 16+kHz region of a VBR encoded
file vs the 256S cbr.
http://users.belgacom.net/gc247244/extra/why_oh_why.png [8KB]
is a _very_ striking illustration, and I started thinking
I was wrong, earlier lame's encode the same way as the newer
alphas. I am still surprised however at the bitrate selected for this
piece. VBR 2 chooses 112 for 83% of the frames in this 3 second
clip. With my volume maxed out I can barely hear the "sound". I
guess I'm just a
I'm using new Win32 compiles from Dmitry. There appears to be a bug in LAME
3.84 CVS where it won't start encoding some WAV files (LAME -q1 file.wav). It
just sits there doing nothing probably in an infinite loop. -q2 works fine. I
managed to encode an entire album but for another album
Hello Mark,
Tuesday, May 23, 2000, 8:14:18 PM, you wrote:
MT Actually, there really are 22 "critical bands" or "scale factor bands"
MT used by MP3. I guess we should stick to the C convention, and call the
MT last band the 21'st band. Here are the frequency ranges,
MT along with the ATH:
MT
Hello,
Is there use for 320kbit/s frames in JS mode? Lame -V1 -mj -h -b128
gives them regulary, and I remember someone told me that the max for
each channel is 160kbit/s anyways, so there would be no quality
improvement?
or
- are the saved bits used for bit reservoir?
- to avoid switching too
On Tue, May 23, 2000 at 10:03:01PM +0200, Roel VdB ([EMAIL PROTECTED]) wrote
Hello Mark,
Tuesday, May 23, 2000, 8:14:18 PM, you wrote:
MT Actually, there really are 22 "critical bands" or "scale factor bands"
MT used by MP3. I guess we should stick to the C convention, and call the
MT
Hello,
Is there use for 320kbit/s frames in JS mode? Lame -V1 -mj -h -b128
gives them regulary, and I remember someone told me that the max for
each channel is 160kbit/s anyways, so there would be no quality
improvement?
No such maximum. You can, for example, encode a mono file
at
Right, just committed a fix for a silly little bug which prevented mp3input
to work together with libsndfile...
I also noted that the --decode feature doesn't care about endianess, thus
ending up with a big endian wav (read; garbage. ;) ) on big endian machines.
Couldn't think up a quick fix
12 matches
Mail list logo