Hi all... I'm using Exact Audio Copy to do my ripping and encoding (well, EAC runs LAME to do the encoding.) Anyway, EAC has an option to analyse the "gaps" in between tracks and save them as part of the songs, or to leave them out. Is this desirable? I guess the theory is that if I was listening to the entire album, and I had gapless playback (I know, we don't yet) then the album would sound exactly as intended with the proper gaps between tracks. But is there a problem with just leaving these gaps out? Or do the songs kind of run together or abruptly change? I know it's picky, but if I'm going to do all this ripping, I want it to sound right...

---
MkII 080000554

Oh NOOOOOO...

TAKE COVER EVERYBODY!



One of the few remaining Mk1 owners... #00015

huh?

---
MkII 080000554

:-) There has been an approximately endless discussion on
how to¨get rid of gaps between tracks.
(For those albums where the songs flow into eachother)

/Michael

Yeah I know... But this wasn't really relevant to that discussion. That was more of a technical "can we do it" and the answer is not 100% since the player has a tiny bit of a gap. I was just asking if the gap removal in EAC works well, and if I should use it, or keep the gaps as part of the tracks. I think it's probably best to leave them in but I was wondering what people think. More of a subjective discussion.

---
MkII 080000554

As far as I know, that option in EAC isn't related to seamless/gapless playback. I wish it was- somebody needs to write a ripper that handles that stuff correctly.

No, I think what it means is this:

On albums where the songs begin and end with silence, do you want to automatically trim off the silence so that the songs begin and end with the first/last bit of wave data?

The purpose is to reduce the file size of the MP3 a tiny bit by not trying to store empty frames. It also makes the songs play "closer together", more like a radio DJ would play them.

___________
Tony Fabris

...reduce the file size of the MP3 a tiny bit by not trying to store empty frames.

A very tiny bit, I think. Just guessing, but you could probably store 1000 seconds of MP3-compressed silence in less space than you could store 1 second of true audio.

It all comes down to what you prefer. FWIW (exactly nothing, I'll wager) I prefer to have the gaps between the tracks. It is unsettling to me to just have the next song start up Bang with no opportunity to reflect, however briefly, on the one just finished.

tanstaafl.



"There Ain't No Such Thing As A Free Lunch"

A very tiny bit, I think. Just guessing, but you could probably store 1000 seconds of MP3-compressed silence in less space than you could store 1 second of true audio.

Actually, with constant-bit-rate MP3 files, silence takes up the same amount of disk space as sound. Each frame is a fixed size, and represents a fixed amount of time as well.

I assume variable bit rate files would drop the bit rates to very low thresholds on silent frames, resulting in smaller frames for the silent parts. But the difference between such frames and the normal-music frames isn't as large as 1/1000.

MP3s aren't exactly like zip files in that respect. The original design was for streaming audio with a relatively constant bit rate.

___________
Tony Fabris

Actually, with constant-bit-rate MP3 files (..) each frame is a fixed size, and represents a fixed amount of time . . .

Now that you mention it, what's the difference between the various encoding methods (128/196 etc). I imagine that the coding rate establishes the number of times (per second) that a new sample is taken, with incremental changes being used to rebuild the recording between samples. Is this so?


Henno
mk2 6 nr 6

I imagine that the coding rate establishes the number of times (per second) that a new sample is taken, with incremental changes being used to rebuild the recording between samples. Is this so?

It sounds like you're confusing sample rate with bit rate.

All MP3s usually have the same sample rate: 44.1khz (the sample rate of the CD they were ripped from).

The bit rate (128, 160, 192, etc.) controls how much data compression they apply to the music. A lower bit rate means that the sound is data compressed more heavily, resulting in more compression artifacts. However, the sample rate (44.1khz, or 44.1 thousand samples per second) doesn't change.

___________
Tony Fabris

As I understand it the bitrate determines the resolution of the psycho-acoustic model. The model is designed to discard detail that has little or no effect to our overall comprehension of the waveform - the lower the bitrate, the more audible detail is lost.

Rob

MP3s aren't exactly like zip files in that respect.

Fascinating! You must have known exactly what I was thinking. I had always assumed (based on nothing but pure ignorance) that audio compression was like text compression -- the less variety, the more compression.

Thank you for explaining it.

tanstaafl.

"There Ain't No Such Thing As A Free Lunch"

I had always assumed (based on nothing but pure ignorance) that audio compression was like text compression -- the less variety, the more compression.

Audio compression can be that way, depending on the implementation of the compression algorithm. MP3 at a constant bit rate isn't like that, however.

And with audio, what counts as "variety" isn't the same as you'd find in a text file. With audio, it tends to be high frequency information that's hardest to compress.

___________
Tony Fabris

ALL MP3s usually have....

I read that part of your message completely all the way through.

Calvin "ugh ;)"

Just to throw in my 0.01 US cents worth,

The thing to remember is that MPEG was designed as a streaming protocol. A stream of data comes off your DVD player and gets decoded on the fly into video and sound; no need to decompress it beforehand. Likewise, you can use this on, say, a video or audio link, by compressing as you read the signal on one side, sending the compressed signal, and then decoding it on the fly at the other end.

It's easier to make a player that will always compress using a certain bit rate, because that implies a certain size of the DCT matrices and so forth. 128kbit is the bit rate that gives you 'CD Quality' over pretty much any signal. Granted, people are learning what the artifacts of MP3 compression sound like and are identifying them in these former CD Quality streams, but the standard isn't perfect. And also consider that it's easier to allocate a fixed amount of bandwidth in a network to that stream than it is to hope that your encoder isn't going to throw a huge spike of data at you at just the same time as the rest of your network is saturated.

It also takes much longer - usually twice the time - to compress a VBR file due to the fact that the compressor has to go through its encode loop a number of times to see which encoding is best. It's not a process like whittling down a square peg to go in a round hole - trim a bit off here and a bit off there until you get to the quality you want. It's more like trying to find the square hole in a large collection of differently shaped holes - in the encoder's terms if you're throwing more information away it sometimes changes your original DCT parameters, which are the basis for all the subsequent steps.

Not that I'm an expert in how the MPEG layer 3 compression actually works, but I think I understand the basics. The uptical pracshot is that LAME usually takes about twice the time (on my machine, a Celeron running at 525MHz) to compress a VBR file as a CBR file of roughly the same bitrate.

Save the whales. Feed the hungry. Free the mallocs.