Hydrogenaudio Forums > The mysteries of the encoder offset... ?

Full Version: The mysteries of the encoder offset... ?

Hydrogenaudio Forums > Lossy Audio Compression > MP3 > MP3 - Tech

PhileasFogg

Feb 8 2004, 21:51

EAC has this option:

"Use offset correction for encoding and decoding"

___ Sample Offset

[Detect Offset]

How does this really work? It seems like *no one* uses it. I'm assuming that I can use it to *minimize* (although not eliminate) the gaps between tracks on playback, but does that depend on which decoder is doing the playback?

I'm encoding with lame.exe 3.95.1 and listening on winamp 5, default decoder (any need for mpg123 these days?) and on my portable RIO VOLT SP250. Minimizing gaps is more important for me in winamp than with the portable player.

This site:

http://mp3decoders.mp3-tech.org/decoders_lame.html

lists

Encoder Overall Delay Encoder Delay Decoder Delay VBR header
FhG l3enc 2.72 1393 864 529
FhG mp3 Prod Pro 1.1 1393 864 529
FhG mp3 Prod Pro 2.1 1393 864 529
FhG mp3enc3.1 1688 1159 529
FhG FastEnc CBR 1201 672 529
FhG FastEnc VBR 2353 672 529 1152
Lame CBR 1105 576 529
Lame VBR 2257 576 529 1152
BladeEnc 1057 528 529

which gives me no idea which of these 4 values to use in the field in EAC. Also, it is not for the most recent version, so the delays may have changed!

to make matters worse, LAME compensates for its own offset, so i always get a value of zero when i test in EAC--but i won't be listening using LAME, i will be listening in winamp and on my RioVolt!

Please somebody set me straight on this--I've be researching it for hours to whatsoever no avail!

ChangFest

Feb 9 2004, 11:52

QUOTE

I'm encoding with lame.exe 3.95.1 and listening on winamp 5, default decoder (any need for mpg123 these days?) and on my portable RIO VOLT SP250. Minimizing gaps is more important for me in winamp than with the portable player.

Why not encode with LAME like you are doing and playback through foobar2000 which supports gapless playback?

QUOTE

How does this really work? It seems like *no one* uses it. I'm assuming that I can use it to *minimize* (although not eliminate) the gaps between tracks on playback, but does that depend on which decoder is doing the playback?

Using offset correction doesn't have much of anything to do with the encoding process. Offsets are the result of audio cds not having any sector location information(Data CDs have sector location info so it's not a problem). CDrom drives have an offset when reading audio cds because it's hard to locate exact sectors on an audio cd. If you can determine the exact offset of your drive, you can theroretically make an exact copy of an audio cd. It does not have much to do with creating perfectly gapless encodes.

Here's a link that explains offsets very well.

damaki

Feb 9 2004, 12:55

QUOTE(ChangFest @ Feb 9 2004, 07:52 PM)

Using offset correction doesn't have much of anything to do with the encoding process.

In fact encoder offset also exists. I don't really know what it is but EAC has a codec offset funtionnality, not only the drive one. Have a look in EAC compression options, in the offset tab.

kode54

Feb 9 2004, 13:07

You do not need that feature when encoding with LAME.

ChangFest

Feb 9 2004, 17:26

QUOTE

You do not need that feature when encoding with LAME.

That's pretty much what I meant when I said, " Using offset correction doesn't have much of anything to do with the encoding process."

QUOTE

In fact encoder offset also exists. I don't really know what it is but EAC has a codec offset funtionnality, not only the drive one. Have a look in EAC compression options, in the offset tab.

QUOTE

Use Offset Correction for encoding and decoding: (Default: Disabled, Recommended: Disabled) Some compressors do not compress the audio data as is, but they introduce an offset error so that at the beginning is silence and at the end often these number of samples (or more) are missing. This could be bad for compressed live recordings, as they can't be reproduced without gap anymore. By specifying this flag on compression the file will be stuffed and on decompression, by using the offset, the original file could be reconstructed (in most cases).
I do not recommend to use this option. The offset detection uses the default installed codec to determine the offset of the selected compressor, and this codec is not per definition the decoder you use to decode the files! For example, if you use the LAME encoder and have the Fraunhofer codec installed for playing MP3 files, EAC will detect and use the offset between those two. However when you use LAME to decode your files instead of Fraunhofer you are using the wrong offset! And if you distribute your compressed files, how can you know which decoder the recipients will use to decode your files. Some encoders (LAME for example) even already correct their own offset (that is if you use LAME for both encoding and decoding). Thus leave this option disabled unless you know what you are doing and are sure that you have the correct offset correction!

Taken from The Coaster Factorie's tutorial for Ripping with EAC.

Link

PhileasFogg

Feb 12 2004, 18:02

ok that argument seems a little strange--sure, LAME compensates for its own offset, but, if i'm not mistaken, don't most decoders perform no compensation whatsoever? Wouldn't the ideal situation be a file with the encoder's offset totally removed, so it would play back totally accurately on any decoder (except LAME itself..)??

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.