Analysing... wav?

[jeff_nz]

I understand from the changelog that the new version does a dummy decode pass before burning, but when I burnt a wav image I noticed it doing it's analysing thing also, which seemed a little redundant to me... (decode wav to wav)

 

I burnt the same audio cd using a cue/bin as source instead of the cue/wav and it starts the burn straight away without the analysis step, so I'm wondering if it's really necessary for a wav file? I had assumed, until today, that the dummy decode pass was just for compressed audio files.

[LIGHTNING UK!]

It's not decoding to wav, it's decoding to PCM.

 

That may or may not mean it just strips the wav header off. Not all wav files are 44khz, 16bit stereo remember!

 

I let DirectShow decide.

[jeff_nz]

Sorry I guess I was unclear, my point was, why is it doing a dummy pass when you have a single wav file (image) as the source... I mean it's purpose is described as "leading to less gaps/padding and no missing audio data" but isn't it unnecessary if the input file is already seamless? (no potential gaps to fix!) That's why I said it seemed redundant, to me anyway.

 

(the same rationale with a single flac file with embedded cue sheet too as the source)

[LIGHTNING UK!]

lol yup you were very unclear if that's what you were trying to say in your first post!

 

I would say the 'leading to less padding and no missing audio data' still applies even if the 'gaps' part doesn't.

 

I guess it could be fine tuned if the user really doesn't want to wait the extra 30 seconds.

[jeff_nz]

Oops, well I knew what I meant anyway.....

 

I wouldn't fine tune it just for me, I don't have a problem waiting 30 second per se... my only motivation for bringing it up was to improve an already great program, so it's your call.

 

BTW, has something changed with the gap detection routines in Read mode with this version? I get different gaps in 2.4.1.0 compared to 2.4.0.0 and the result is consistent over 2 drives.

[LIGHTNING UK!]

Erm I seem to recall having to fix something in that area yes.

 

One of the commands returns info in a different format to the others and I hadn't noticed that in the initial 2.4.0.0 release.

 

How 'different' are your gaps exactly?

 

Are they different *wrong* or just different?

[jeff_nz]

How 'different' are your gaps exactly?

As in by how much different, or...? Typically by 0.3 sec

 

Are they different *wrong* or just different?

Well different *wrong*... that is to say, 2.4.1.0 gets it wrong whereas 2.4.0.0 detects the correct gap (or within 0.01)

 

I've just been checking a few more CD's apart from my usual test CD, and it's only on some tracks that it detects the wrong gap, not every track, but it seems to be a consistent pattern for 2.4.1.0.

 

Hmmm.... on closer inspection it almost appears as if it's rounding up sometimes?

 

I'm looking at several tracks now, each with a gap of 1.70 sec on the original cue sheet, and after being burnt 2.4.1.0 is reporting the gap for those tracks as 2.00 sec, while both 2.4.0.0 and EAC are detecting it as 1.70 sec, which we know it should be.

 

Anyway it's only a minor thing but I thought you'd want to know....

 

(and hopefully I've explained myself clearly *this* time. )

[LIGHTNING UK!]

That'll be pregap snapping then.

 

Look in the options.

 

btw, 3 frames is not 0.3 seconds!

 

There are 75 frames per second, which I sure you already know if you think about it.

[jeff_nz]

Thanks, I didn't know about that option, now it all makes sense!

 

Also, forgive my lack of technical knowledge on the inner workings of cue sheets, but you learn something new every day...

[LIGHTNING UK!]

Drives aren't always 100% accurate with their pregap timings and I figured there's very little reason to have something like 72 frames or 77 frames for a pregap, hence it snaps to the nearest multiple of 75 (nearest second) if it's within the configured pregap snapping range.