Jump to content

Analysing... wav?


jeff_nz

Recommended Posts

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) :huh:

 

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

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

 

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.