Offset correction for read/write audio CDs.

[Pestam]

Like EAC has it. Any chance you're going to implement it?

[LIGHTNING UK!]

I don't really know enough about it, nor am I that much of an audiophile.

[Pestam]

Ok, it's not really that important as it may sound. It's just one of the standard question about audio rippers.

 

Another question like that would be: Are you planning to support secure ripping of audio CDs?

[JasonFriday13]

Just use EAC instead. It's the only audio ripper I use. Why replicate it if it's already in a great piece of software?

[snatch]

I want to up the suggestion about offsets once again.

I think, it is the only missing thing in order to use ImgBurn as a bit-perfect CD copier.

 

While CD ripping is quite a commonplace software now, but very few of them has support for read offset correction,

and only EAC has working support for write offset correction (btw, the built-in EAC writer is far from perfection, comparing to ImgBurn).

It would be nice if ImgBurn became the second program with write offset support.

 

ImgBurn has excellent ability to read .cue sheets + lossless images (presumably ripped with read offset correction),

and it's a pity not to have the ability to use the write offset correction when burning Audio CDs.

 

 

ps. Since it's my first post, I'd like to say "thank you very much" to the author for such a solid piece of software.

[batagy]

If you want an offset corrected burnt audio disc, then you can use a tool called "Cue Tools" for setting the offset on the audio files themselves, before you burn them with ImgBurn.

Look this tool here:

http://www.hydrogenaudio.org/forums/index....showtopic=50113

[WinTakeAll]

If you want an offset corrected burnt audio disc, then you can use a tool called "Cue Tools" for setting the offset on the audio files themselves, before you burn them with ImgBurn.

Look this tool here:

http://www.hydrogenaudio.org/forums/index....showtopic=50113

 

Thanks for that suggestion of a workaround. But since write offset is inherently a per-drive parameter, it would make more sense to be able to configure it for your drive in your burner program than to configure it for the .cue file which is meant to remain useful for any drive.

 

So it would still be valuable to see this feature added to ImgBurn.

[WinTakeAll]

I don't really know enough about it, nor am I that much of an audiophile.

It's reasonably simple, really: On writing a track, just either remove the first N samples, or add M zero samples before it to compensate for what actual drives do to the track. Just offer a per-drive setting to specify the number of samples and the sign, and your advanced users will be able to find out the correct value for their drives and make copies that as far as possible remain bit-perfect, even after multiple generations.

[LIGHTNING UK!]

When you say 'write offset', is it basically where I write 2352 bytes of data (i.e. an audio sector) to a certain LBA and then read it back and the two differ?

 

If I compare the two, I should then find that at a certain offset, the data from the read begins to mirror exactly what was written, with the stuff before it just being junk?

 

I guess it wouldn't be hard to just insert a few bytes of nothingness into the buffer before the real data.

 

I noticed that during my own testing actually. The only drive that seemed able to write exactly what I sent it (so I could compare it exactly when read back) was my Lite-On.

[WinTakeAll]

When you say 'write offset', is it basically where I write 2352 bytes of data (i.e. an audio sector) to a certain LBA and then read it back and the two differ?

 

If I compare the two, I should then find that at a certain offset, the data from the read begins to mirror exactly what was written, with the stuff before it just being junk?

 

I guess it wouldn't be hard to just insert a few bytes of nothingness into the buffer before the real data.

 

I noticed that during my own testing actually. The only drive that seemed able to write exactly what I sent it (so I could compare it exactly when read back) was my Lite-On.

 

That's exactly what it is. When reading or writing audio data, almost all drives shift the position by a fixed amount that is specific to the make and model of drive. Usually a few hundred samples on reading and a few tens of samples on writing. Your favorite search engine or a quick test should be able to tell the value for your drive. But not the manual.

 

On a few drives, probably including your Lite-On, the read and write offsets are the same but with opposite signs so it appears that you read exactly the same data back that you wrote, with no shifting. This is often described as having a zero combined read/write offset.

 

But in that case you may still find that the data was read with an offset if you write the data back on a different drive, even if that other drive also has a zero combined read/write offset. So the ideal way to deal with it is to find both the read and the write offset and apply each as needed. That's what EAC does. It lets you read your discs on one drive and write them on another with no shifting if you configured your offsets correctly.

 

If there are drives out there that have a zero offset for both reading and writing, I don't know about them. On the other hand it always puzzled me why drive firmware developers don't make sure all drives are like that. I guess they just don't think it matters for audio. (Or is it another feeble RIAA conspiracy against CD copying?) Imagine if a file system worked like this though...

Edited April 4, 2008 by WinTakeAll

[LIGHTNING UK!]

It is indeed odd, like you say, it would be hell if it did it on data sectors!

 

A 'sample' of CD-DA is just 4 bytes yeah? (remember I'm not an audio person and generally deal in 'sectors' when burning stuff!)

[WinTakeAll]

A 'sample' of CD-DA is just 4 bytes yeah?

 

Correct. 16 bits times 2 channels for stereo = 4 bytes. The shifting is always in multiples of such 4-byte samples, so that's the unit the community uses to measure this shifting for any given drive.

 

(If it ever were shifted a non-4-byte multiple the audio would be seriously screwed up, or at least channel-swapped, but fortunately we don't see drives do that. So of course it's important that we don't give users the ability to do anything but shifting in multiples of 4-byte samples either.)

Edited April 4, 2008 by WinTakeAll

[snatch]

Just to refresh the suggestion...

 

LIGHTNING UK!

Do we have a chance to see this feature in the next ImgBurn releases? (Given you've asked for details...)

[LIGHTNING UK!]

Maybe one day/year, yeah.

[JensL]

It's a great nice-to-have feature and I use EAC for this, too.

[rosanna]

Maybe one day/year, yeah.

i would love this feature

read and write offset

it's not hard there is a database with almost every offsets drive values

 

 

if i make a donation , can i have this feature? i'm not kidding :innocent:

[dontasciime]

It's not hard

 

Never is

[LOCOENG]

It's not hard

 

Never is

 

They make drugs for that now a days Donta

[mmalves]

[rosanna]

It's not hard

 

Never is

 

They make drugs for that now a days Donta

i got it

i will never see this feature

[rosanna]

sorry but trento is in italy? or in brazil??

i know it

Edited October 9, 2008 by rosanna

[Yesallright]

it's not hard there is a database with almost every offsets drive values

This database you mean? Isn't it a read-offset datbase, rather than write-offset?

[Surfy]

::

 

Yes, this would be an absolutely awesome feature. There's no need to have a read offset correction in ImgBurn (... it's not ImgRip - it's ImgBurn ). But it would be very nice to have that manual write offset correction EAC offers. Many drives are not supported by EAC's write engine. For further reading:

 

Offset Questions >> Exact Audio Copy

OFFSETS

 

 

Greetings ...

 

::

Edited August 14, 2009 by Surfy

[Surfy]

::

 

2.5.0.0 ... no write offset correction yet ...

 

::

[John_Anderson]

Write offset correction would be an amazing addition.