My whole life I've been listening to my music on 22.5 KHz 56/64 kbps
because it bore little to no difference to the original for me, and
cuz I felt like 128 kbps was unnecessarily wasteful. Everyone was
telling me "Man, how can you listen to that garbage, like how do you
even make out the words in that song with such low quality?" I thought
they were all being tightasses. But I did realize my choice of quality
was, in fact atypical, so I asked one of my friends what exactly is
the difference between 64 kbps and 128 kbps audio to him. He said that
it's pretty hard to explain, but "instead of listening to music with
headphones that block out all the surrounding environment, try
comparing it at a party with real speakers and you'll hear the
difference."

Now, just recently I was at the Doctor and had my ears done, and now I
hear 10x better than before and FINALLY I noticed what I've been
missing my whole life... 56 kbps is just so friggin' DULL as if the
singers got their mouths stuffed full of cock. It appears before I
could not perceive higher frequencies (e.g. 44.1 sounded the same as
22.5 to me) and so I could tolerate lower bitrates and... I dun think
you guys need more details, cuz the difference between 64 and 128
would probably be OBVIOUS to you.

So, I've re-downloaded all my songs and now most of 'em are at 80, 96
and 128 kbps but NONE below 80 anymore. However, I wanna know the
best, most economic way to encode or re-encode audio to MP3 and keep
the quality.

Currently, I use this script:

lame.exe song.wav -o song.mp3 --abr 128 [80-160] -q 0

A couple questions:

1. Does the choice of frequency (e.g. 44100) significantly affect the
bitrate, and vice versa? If so, is 48 KHz really necessary for most
songs?

2. Are there any disadvantages to using Variable Bit Rate when
encoding?

3. Does constantly re-encoding the audio fuck its quality up --
especially when switching from constant bit rate to VBR?

4. How do I know the bit rate I've chosen is ideal? By which I mean:
when I encode at 160 kbps and the output MP3 results with an average
of 137 kbps, was this the right choice? And when I encode at 144 I get
132. Which of these is the better choice?

Most of the time the average bitrate was lower than the target bitrate
set, does it mean I have picked an ideal range? I tried to encode the
same song to 64 kbps once and I got 70 kbps instead. My guess is that
if the output bitrate was higher than the target, it means more bits
were required than chosen and the encoder was straining to keep the
quality while at the same time trying to satisfy the demand to be more
or less 64 kbps.

5. Is 96 kbps good enough for general purpose audio instead of 128? I
notice no difference between the two, with some exceptional fast-paced
songs with high hypervarying frequencies.

Thanks in advance.

industrial_one@hotmail.com wrote:

Congratulations on the ear upgrade.

> 1. Does the choice of frequency (e.g. 44100) significantly affect the
> bitrate, and vice versa? If so, is 48 KHz really necessary for most
> songs?

It depends on the data content.  If there is high frequency sound 
(cymbals, etc., anything over 11khz or with recorded harmonics over 1khz 
that mp3 isn't taking care of completely), then if you can hear that 
stuff, then you will be able to tell the difference.  Whether it is 
necessary depends on what you want to hear.


> 2. Are there any disadvantages to using Variable Bit Rate when
> encoding?

It may take a little longer to encode, but generally it "does the right 
thing" when encoding audio: low-content audio gets fewer bits than 
high-content audio (where 'content' is more or less 'more non-modeled 
frequencies').


> 3. Does constantly re-encoding the audio fuck its quality up --
> especially when switching from constant bit rate to VBR?

If you have 56kbit.mp3 -> wav -> 96kbit.mp3, you aren't gaining anything 
in the transition except for taking more space.  Once you have lossey 
encoded data to a low bitrate, there is *no way* to get that data back. 
  Find some .wav (optimally by ripping it yourself) with the proper 
features, or if you can't get it any other way, starting out with an mp3 
of higher bitrate than what you want to end up with and reencode with 
that.  It won't have as high a quality as if you started out with a wav, 
and hard drive space is cheap ($90 for 300 gigs), so I would suggest 
just downloading with bitrates at least as high as you want to listen 
and not bothering to reencode.


> 4. How do I know the bit rate I've chosen is ideal? By which I mean:
> when I encode at 160 kbps and the output MP3 results with an average
> of 137 kbps, was this the right choice? And when I encode at 144 I get
> 132. Which of these is the better choice?

If you give it more bitrate and it uses more bitrate, then it needed 
more bitrate (or thought it did) to accurately represent the sounds.  If 
you can tell (heck, even if you cant, and you want people to listen to 
music with you), and you have the extra space, go with the higher 
quality stuff (though you will tend to get the best quality by not 
reencoding from a source mp3, and only starting from CD or some other 
losslessly encoded audio; like FLAC, Monkey lossless, etc.).


> Most of the time the average bitrate was lower than the target bitrate
> set, does it mean I have picked an ideal range? I tried to encode the
> same song to 64 kbps once and I got 70 kbps instead. My guess is that
> if the output bitrate was higher than the target, it means more bits
> were required than chosen and the encoder was straining to keep the
> quality while at the same time trying to satisfy the demand to be more
> or less 64 kbps.

Generally yes, but for the sake of processing time, it may be only 
making one pass over the data, which makes it more or less impossible 
for it to correctly distribute bitrates through the song to produce your 
desired output size.  If there were multiple pass variable bitrate 
encoding (like you see in movie encoding), you could get the bitrate 
more or less exactly what you want.  Then again, a 10% over-bitrate 
isn't that bad.


> 5. Is 96 kbps good enough for general purpose audio instead of 128? I
> notice no difference between the two, with some exceptional fast-paced
> songs with high hypervarying frequencies.

If you can tell the difference with your ears, then it is likely that 
others can hear the difference with theirs.  I personally can tell the 
difference in quality between 64, 96, 128, and 196 even with poor 
quality headphones, so I usually go for 196 or better.

If you friends can tell the difference, and you want them to listen to 
music with you, use higher bitrate (or just use the higher quality stuff 
from their ipods, etc.).


  - Josiah

On Jul 15, 10:42 am, Josiah Carlson <josiah.carl...@sbcglobal.net>
wrote:
> industrial_...@hotmail.com wrote:

> Congratulations on the ear upgrade.

Thanks. I might've been deaf or something... I thought I heard you
killfile me o.O

> It depends on the data content.  If there is high frequency sound
> (cymbals, etc., anything over 11khz or with recorded harmonics over 1khz
> that mp3 isn't taking care of completely), then if you can hear that
> stuff, then you will be able to tell the difference.  Whether it is
> necessary depends on what you want to hear.

Ahh yes, I did notice when I downgraded a song from 192 to 96 that the
'triangle' sounds were kinda duller so I just did 128. (but still at
44.1) My question was if 48 KHZ is necessary for ANY song, to my
experience I thought 44.1 covers pretty much everything. It doesn't
matter anyhow, an entire 20-minute audio from this episode was about
15 MB at 48 and only 200 KB smaller at 44.1. So whatever.

I got another question: Precision: 8-bit and 16-bit. Is there a
difference?

> > 2. Are there any disadvantages to using Variable Bit Rate when
> > encoding?
>
> It may take a little longer to encode, but generally it "does the right
> thing" when encoding audio: low-content audio gets fewer bits than
> high-content audio (where 'content' is more or less 'more non-modeled
> frequencies').

Ya thats what I thought, so no disadvantages other than taking
somewhat longer to encode/decode. And... "non-modeled freqs"?

> > 3. Does constantly re-encoding the audio fuck its quality up --
> > especially when switching from constant bit rate to VBR?
>
> If you have 56kbit.mp3 -> wav -> 96kbit.mp3, you aren't gaining anything
> in the transition except for taking more space.  Once you have lossey
> encoded data to a low bitrate, there is *no way* to get that data back.
>   Find some .wav (optimally by ripping it yourself) with the proper
> features, or if you can't get it any other way, starting out with an mp3
> of higher bitrate than what you want to end up with and reencode with
> that.  It won't have as high a quality as if you started out with a wav,
> and hard drive space is cheap ($90 for 300 gigs), so I would suggest
> just downloading with bitrates at least as high as you want to listen
> and not bothering to reencode.

I mean, lets say encoding a wav to 64kbit.mp3 then converting it back
to wav to do some editting to the song and converting again to
64kbit.mp3. Most people told me this does diminish the quality (as
would re-saving a JPEG over and over.)

> that.  It won't have as high a quality as if you started out with a wav,
> and hard drive space is cheap ($90 for 300 gigs), so I would suggest
> just downloading with bitrates at least as high as you want to listen
> and not bothering to reencode.

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

> > 4. How do I know the bit rate I've chosen is ideal? By which I mean:
> > when I encode at 160 kbps and the output MP3 results with an average
> > of 137 kbps, was this the right choice? And when I encode at 144 I get
> > 132. Which of these is the better choice?
>
> If you give it more bitrate and it uses more bitrate, then it needed
> more bitrate (or thought it did) to accurately represent the sounds.  If
> you can tell (heck, even if you cant, and you want people to listen to
> music with you), and you have the extra space, go with the higher
> quality stuff (though you will tend to get the best quality by not
> reencoding from a source mp3, and only starting from CD or some other
> losslessly encoded audio; like FLAC, Monkey lossless, etc.).

I see.

> > Most of the time the average bitrate was lower than the target bitrate
> > set, does it mean I have picked an ideal range? I tried to encode the
> > same song to 64 kbps once and I got 70 kbps instead. My guess is that
> > if the output bitrate was higher than the target, it means more bits
> > were required than chosen and the encoder was straining to keep the
> > quality while at the same time trying to satisfy the demand to be more
> > or less 64 kbps.
>
> Generally yes, but for the sake of processing time, it may be only
> making one pass over the data, which makes it more or less impossible
> for it to correctly distribute bitrates through the song to produce your
> desired output size.  If there were multiple pass variable bitrate
> encoding (like you see in movie encoding), you could get the bitrate
> more or less exactly what you want.  Then again, a 10% over-bitrate
> isn't that bad.

Cool, how do I set l.a.m.e to do multipasses?

> > 5. Is 96 kbps good enough for general purpose audio instead of 128? I
> > notice no difference between the two, with some exceptional fast-paced
> > songs with high hypervarying frequencies.
>
> If you can tell the difference with your ears, then it is likely that
> others can hear the difference with theirs.  I personally can tell the
> difference in quality between 64, 96, 128, and 196 even with poor
> quality headphones, so I usually go for 196 or better.

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

> If you friends can tell the difference, and you want them to listen to
> music with you, use higher bitrate (or just use the higher quality stuff
> from their ipods, etc.).
>
>   - Josiah

I'll do that.

Thanks for all the info, Josiah. +1

industrial_one@hotmail.com wrote:
> On Jul 15, 10:42 am, Josiah Carlson <josiah.carl...@sbcglobal.net>
> wrote:
>> industrial_...@hotmail.com wrote:
> 
>> Congratulations on the ear upgrade.
> 
> Thanks. I might've been deaf or something... I thought I heard you
> killfile me o.O

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.


>> It depends on the data content.  If there is high frequency sound
>> (cymbals, etc., anything over 11khz or with recorded harmonics over 1khz
>> that mp3 isn't taking care of completely), then if you can hear that
>> stuff, then you will be able to tell the difference.  Whether it is
>> necessary depends on what you want to hear.
> 
> Ahh yes, I did notice when I downgraded a song from 192 to 96 that the
> 'triangle' sounds were kinda duller so I just did 128. (but still at
> 44.1) My question was if 48 KHZ is necessary for ANY song, to my
> experience I thought 44.1 covers pretty much everything. It doesn't
> matter anyhow, an entire 20-minute audio from this episode was about
> 15 MB at 48 and only 200 KB smaller at 44.1. So whatever.

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.


> I got another question: Precision: 8-bit and 16-bit. Is there a
> difference?

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


>>> 2. Are there any disadvantages to using Variable Bit Rate when
>>> encoding?
>> It may take a little longer to encode, but generally it "does the right
>> thing" when encoding audio: low-content audio gets fewer bits than
>> high-content audio (where 'content' is more or less 'more non-modeled
>> frequencies').
> 
> Ya thats what I thought, so no disadvantages other than taking
> somewhat longer to encode/decode. And... "non-modeled freqs"?

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.


> I mean, lets say encoding a wav to 64kbit.mp3 then converting it back
> to wav to do some editting to the song and converting again to
> 64kbit.mp3. Most people told me this does diminish the quality (as
> would re-saving a JPEG over and over.)

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).


>> that.  It won't have as high a quality as if you started out with a wav,
>> and hard drive space is cheap ($90 for 300 gigs), so I would suggest
>> just downloading with bitrates at least as high as you want to listen
>> and not bothering to reencode.
> 
> $90 for 300 gigs? Holy shit. 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.

> 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).

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

Yeah, just a brief mind fart.

  - Josiah

Josiah Carlson wrote:

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

Mostly right, except that it's DCT, and not DFT. The Discrete Cosine
Transform used in MPEG Audio is also overlapped over neighboring
blocks to prevent audible clicks at block boundaries (the Modified
DCT, or MDCT)

http://en.wikipedia.org/wiki/MP3
http://en.wikipedia.org/wiki/Modified_discrete_cosine_transform

It also uses a more complex audio model to remove not only high
frequencies, but any frequencies you should'nt be able to hear
anyway, because of auditory masking. That is, if a given frequency
is loud enough, it can prevent other, quieter, frequencies from
being heard. So they can be removed as well. The model is by no
mean trivial.

http://en.wikipedia.org/wiki/Psychoacoustics
http://en.wikipedia.org/wiki/Auditory_masking



best,

	S.

On Jul 15, 6:42 pm, Josiah Carlson <josiah.carl...@sbcglobal.net>
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 shit-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 shit. 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.

Fuck! 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? :)

Steven Pigeon wrote:
> Josiah Carlson wrote:
> 
>> 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.
> 
> Mostly right, except that it's DCT, and not DFT. The Discrete Cosine
> Transform used in MPEG Audio is also overlapped over neighboring
> blocks to prevent audible clicks at block boundaries (the Modified
> DCT, or MDCT)

I mentioned the DCT later in my post when I also discussed jpeg.  I 
didn't go into further discussion about overlapping blocks or 
psychoacoustic modeling because it wasn't necessary to get the point across.

  - Josiah

industrial_one@hotmail.com wrote:
> On Jul 15, 6:42 pm, Josiah Carlson <josiah.carl...@sbcglobal.net>
> 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 shit-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

On Jul 16, 2:07 am, Josiah Carlson <josiah.carl...@sbcglobal.net>
wrote:
> industrial_...@hotmail.com wrote:
> > On Jul 15, 6:42 pm, Josiah Carlson <josiah.carl...@sbcglobal.net>
> > wrote:
>
> > 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.

I see the point, but your analogy is off-key. An image is a different
story, with audio it is pointless going over 48 as no normal human
ears would detect the difference. I'm perfectly cool with a 512x512
image and with 1024, but 2048+ is pointless and just makes viewing a
bitch since my screen only displays 1024x768.

> 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 think I tried that one with a recording of my voice, (converted to
32 bit.)

> Yep.  Also read the other reply to my message by Mr. Pigeon .
>
>
> 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.

I thought I deduced DCT outta context several times but the
description on the Wikipedia article confused me. In a nutshell: how
does the discrete cosine transform work?

> >>> 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

Btw... what about WMA? I have a couple encoded at 64 kbps that
maintain the same quality as a 128 kbps MP3. Does this format employ
multi-pass techniques? Does it detect repeating parts of the song and
in turn compresses twice as MP3 while retaining the quality?

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

Wait... video or audio?

> 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).

No, 128kbit, do the math: 115 MB of audio, 500-something MB of video,
that's about 20% (not 25) which is still a lot.

> 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

I use H264, which takes longer than DivX to encode.

Another thing--this is off-topic but it's my thread so anyway: tell me
about MP3 and digital music in general in teh ancient times. Assuming
you're 30+ you must know what the music days were like in the early
'90s. How did people share their music? What were the formats? If MP3,
what was the most common bitrate used, probably low since disk space
was max 1 GB back then, right?

Tell me all about it. Share the wisdom!!!!!!!!

I asked one old-timer (48) who's been browsing bulletins since mid-80s
and he told me music was distributed in PCM format, I'm like yeah
right and he said they were about the same size as an MP3 which I
called bullshit at first but it made sense when he said it was mono,
22KHz 8-bit (some stereo, some 16-bit.) He said there were boards
where you could download music from if you had a special subscription.

He said MP3s were avail around 1989 but weren't popular cuz it would
not playback in real-time under even cuttin-edge processors at that
time.

Is this accurate?