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

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?

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?

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.

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.

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.

$90 for 300 gigs? Holy ***. I only got 40 gigs, I needa upgrade.

Yeah. I didn't realize it was that cheap myself until I got a call from
my brother this morning asking how to install the (retail from Best Buy)
drive in his machine.

***! I paid $150 to replace my shitty dead cumstained 40 GB drive
with a... 38 GB drive. Those bastards!

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]?
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.

lol @ 196, I never heard of that, did you mean 192?

Yeah, just a brief mind fart.

Drugs are bad for you, m'kay? :)

.