Re: The best MP3 VBR bitrate choice when encoding audio?

industrial_one@xxxxxxxxxxx wrote:
On Jul 15, 6:42 pm, Josiah Carlson <josiah.carl...@xxxxxxxxxxxxx>
wrote:

Thunderbird doesn't have an actual killfile, so I just made it mark
anything you post as read. Since no one had replied to you earlier, I
though that I would be nice and try to help you.

Is Jacko and I the only ones around here who use Google Groups?

I don't know. I just prefer a more standard news interface.


CD audio comes at 44khz, and resampling to 48khz cannot add anything to
the audio quality. 48khz is an option because some sound cards can
record at that frequency (some even do 96khz), in order to offer a
better representation (you need to sample at least twice the frequency
to be able to capture the basic form of a particular frequency, but
sampling at a higher rate gives better quality.

96khz? That's crazy. Better representation? Is there a point?

Can you tell the difference between a 512x512 pixel image and a 1024x1024 pixel image, given that the larger image gets 4x the amount of data storage? Because that's more or less the difference between 22khz and 96khz audio. It's all about signal representation. The more samples you have of a signal, the more precisely you can reproduce the signal.

Yes. I can usually tell the difference, but it may not make a
difference. Compare and contrast.

Damn! I couldn't. When I examine with a hex editor, I see for 8-bit
only 1 byte is used (per sample? or whatever u call it) containing
values mostly in the 50 - C0 range, with 16-bit it's the same values
accompanied by another byte with 0-30. And finally I tried to convert
to 32-bit and most of the extra bytes were 00s. Fruitless extra
precision methinks.

CDs are only 16 bit. Converting it to 32 bit won't get you any more signal range. Further, most sound cards lack the either the recording from analog to digital, or the conversion of digital data to analog sound to such a precision.

I suspect that the audio that you are looking at just doesn't have a high enough "dynamic range" to really offer a decent comparison (in particular, most commercial music produced in the last 5 years has a very limited dynamic range; you will get better quality data by checking out some classical music and/or music mastered prior to 1990).


The basics of MP3 compression relies on what is known as a "fourier
transform". You take the data, you decompose it into it's base
frequencies, then, based on how you know the human ear processes sound,
and how harmonics are generated, you remove some of the higher frequency
stuff (to reduce the data content), etc. If there is some high
frequency sound that wasn't handled by the just-mentioned techniques, it
needs to encode it directly, which is where some of the extra bits go.
With CBR, there is little leeway, so such signals are commonly just removed.

That makes sense, generally the frequency above (or below) the human
perception would be removed I guess, there's also the bit-masking
where some frequencies would be ***-canned by others.

Yep. Also read the other reply to my message by Mr. Pigeon .


It does, for the exact same reasons that doing it to jpeg does it (they
both use discrete cosine transforms to encode the signals, which is a
relative of fourier transforms).

One question... (if I'm right) JPEG works by scanning the raw picture
and replacing the 8x8 areas with the closest resembling macroblock
contained in the dictionary/bank/whatever. If I would compress the
picture again, those areas would contain the same macroblocks and thus
wouldn't be affected. Granted, resizing the picture definetaly would.

I never dug into jpeg heavily, but from what I remember of what I read, part of what it does is to take those blocks and arrange the pixels in a particular order (not row by row or column by column), then use a DCT on *that* signal. Theoretically (if one assumes that the optimal ordering experimentally obtained over 15 years ago applies on the larger scale), one would get the optimum results by applying this to 8x8 blocks of 8x8, then 8x8 blocks of those, etc. I could have sworn that this was what is done, but like I said, I never dug into jpeg heavily.


Cool, how do I set l.a.m.e to do multipasses?
I don't know. I don't even know if lame (or any audio compressor) does
multipass. Generally audio takes so little space (as compared with
video), I don't think anyone has really bothered. Then again, maybe it
does it already (multipass on video is pretty quick, the first pass
taking maybe 15 minutes for a 2 hour movie, movie encode in 1.5 hours or
so).

Little space compared to video? Are you shittin' me? The audio makes
up 25% of an .AVI movie, sometimes more if the ripper was being a
tightass and decided to put in 5 channels 256 kbps surround sound. And
how the hell do you encode a 2-hour movie in [i]FIFTEEN MINUTES[/i]?

The *first pass* takes 15 minutes, which is really only a very simple 'how much does data change from frame to frame' calculation. The second pass typically takes as long as a regular encode, but it uses the extra data to better assign bits to each frame.

As for audio; yes, if the movies you are downloading were ripped with 256kbit audio to a single 700 meg CD, then yes, it will be about 25%. But not all are 256kbit 5-channel sound (back in the day, it wasn't uncommon to find rips using 128kbit stereo sound), or packed onto a single CD. A quick trip to TPB tells me that the top 100 dvd rips are at least a gig, with most around 4 gigs (coincidentally the size of a single-sided, single-layer DVD ;). Unless they are wasting space with multi-language audio, audio is only taking up around 5% of that space (or less).


It would take me about 6 hours to encode a 2-hour movie and my comp is
cutting-edge CPU as of 2001. What codec? MPEG-1 would make sense since
it's a simple algorithm, old and fucked up.

2001 is a long time ago in the realm of computers. My circa 2004 laptop can encode a 2 hour movie using medium-quality DivX better than real time. My office machine is about 3x faster.


- Josiah
.