Potential DirectShow Error

[Elkaton]

Almost every time I burn a CUE file, I end up getting this "Potential DirectShow Error" complaining that no data has been received for 10 seconds. But if I just click "Continue" before the buffer runs out, everything is fine.

 

To make sure that I get the time to notice the error and click "continue", I increased my buffer size to 128M... but it's still a bit annoying. What would you recommend? Can I tell ImgBurn to ignore this somewhere?

 

One thing that's strange is that the error occured well after filling up the buffer, and in this case, the three tracks together actually fit entirely in the buffer. So I guess ImgBurn was waiting for some sort of "transaction complete" message from DirectShow? Why would that take more than 10 seconds to come up?...

 

I 16:01:12 ImgBurn Version 2.4.2.0 started!

I 16:01:12 Microsoft Windows XP Professional (5.1, Build 2600 : Service Pack 3)

I 16:01:12 Total Physical Memory: 3,407,216 KB - Available: 2,749,180 KB

W 16:01:12 Drive I:\ (FAT32) does not support single files > 4 GB in size.

I 16:01:12 Initialising SPTI...

I 16:01:12 Searching for SCSI / ATAPI devices...

I 16:01:12 Found 1 DVD

[LIGHTNING UK!]

W 16:10:53 File Name: C:\Documents and Settings\Administrator\My Documents\Audacity\20081010-Koto\3.wav

W 16:10:53 Index Progress: 39,469,500 bytes

W 16:10:53 Index Size: 40,633,152 bytes

 

'Continue' is the same as 'Ignore', which basically means ImgBurn will be zero filling (digital silence) the remaining 1MB of that file.

 

Do you notice that when it's doing the initial 'analysing' pass (right after you've clicked the write button) that it hangs for a while?

 

I don't see why that stage would work ok and not the real decode pass.

 

Expect a PM from me.

[Elkaton]

'Continue' is the same as 'Ignore', which basically means ImgBurn will be zero filling (digital silence) the remaining 1MB of that file.

 

Do you notice that when it's doing the initial 'analysing' pass (right after you've clicked the write button) that it hangs for a while?

 

I don't see why that stage would work ok and not the real decode pass.

 

Expect a PM from me.

 

Darn. The end of that file was silence so I couldn't tell the difference. I just checked with another audio file, and indeed nulls are burned instead of the last megabyte or so.

 

I sent you the debug logs by PM as requested.

 

This also means that the problem also occurs during a separate verify phase, although no error pops up that time (and it claims a successful verification, but that's now obviously a lie!)

 

This is a bigger problem than I thought.

[Elkaton]

Oh. I just figured out why it wasn't much of a problem before: I was always clicking "Try Again", not "Continue". I checked, and indeed if I click "Try Again" it correctly reads and burn the remaining data.

 

Now now now... As to figuring out why it's taking more than 10s for DirectShow to spew the last megabyte...

[LIGHTNING UK!]

Your disc in the above example is actually just over 128MB in size so it wouldn't fit in the buffer. Increase the buffer to 140 and it will. My guess is that you then won't see the prompt about directshow not returning data (and that's because the problem won't occur, not that it would just hide it).

 

Can I just check that if you mix the songs up in the CUE (i.e. change the order to 3, 1, 2) that with a 128mb buffer it's still the last track that gets the error? My guess is that whichever song the buffer size lines up with is the one that produces the error message.

 

Re. Successful Verification:

 

Due to drives reading and writing CD-DA sectors with an offset (i.e. it doesn't write the data I give it exactly where I tell it to - and every drive is different), it's not possible for ImgBurn to do a byte level comparison on that data type.

 

ImgBurn will just be checking the sectors are readable - which they are

 

The option to make ImgBurn do a byte level comparison on CDDA tracks can be found in the settings - but as it only works for drives where the read/write offset cancel each other out exactly, I don't recommend you change it. It would just make verify mode complain about millions of 'mismatches' on all other drives.

[Elkaton]

Can I just check that if you mix the songs up in the CUE (i.e. change the order to 3, 1, 2) that with a 128mb buffer it's still the last track that gets the error? My guess is that whichever song the buffer size lines up with is the one that produces the error message.

 

Still occurs, but since no error message is written to the log if I click "Try Again", it's hard to tell with what track the problem was (see my reply to your PM).

 

Due to drives reading and writing CD-DA sectors with an offset (i.e. it doesn't write the data I give it exactly where I tell it to - and every drive is different), it's not possible for ImgBurn to do a byte level comparison on that data type.

 

ImgBurn will just be checking the sectors are readable - which they are

 

The option to make ImgBurn do a byte level comparison on CDDA tracks can be found in the settings - but as it only works for drives where the read/write offset cancel each other out exactly, I don't recommend you change it. It would just make verify mode complain about millions of 'mismatches' on all other drives.

 

Ah! Right. Indeed, if I extract the data back there's an offset, 65 samples worth. I keep forgetting that CDDA is so imprecise...