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.

It'll never happen, sorry.

Yes, it will have read all the sectors on the disc and if it didn't error out then the drive thought they were fine at the time. This a drive issue if it didn't pick them up the first time around, ImgBurn can only go by what it reports. Post the log of your burn/verify and maybe we'll be able to spot something that could cause the problem - i.e. outdated firmware/old drive/cheapo media.

Verify confirms that at that moment in time, in that specific drive, all the sectors were readable and matched what's in the original image. If you think there's a problem, verify it again and double check.

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?

If the source is OTP, ImgBurn will always be able to use the LB position from the MDS - as it will always be valid. The only time it can't is if L1 > L0 (which only happens on *some* PTP media) and then it has to fall back to scanning the IFOs / Cells etc trying to find one that is acceptable. When it can't, it then throws up that error box. At this point you have 2 choices (or maybe just 1, I can't remember!): 1. Ignore getting a nice LB and just divide the image in 2. 2. Rebuild the image via a virtual drive and Build mode.

I wish the drive people would implement a proper way to disable the auto write/verify without me having to resort to using the 'streaming' command. There seems to be a flag I can set that does exactly that on BD-R but it doesn't apply to BD-RE... what I don't get is that BD-R burns at the correct speed anyway! I guess the only timesaver is that you can disable the program's Verify feature if FastWrite is not enabled - there's no point in verifying twice!

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.

I didn't expect my latest release to fix your *glitch*, but it probably did fix a few other little things.

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.

Who's to say anyone would understand what PTP and OTP means?! I guess I could turn the error into an essay

Fastwrite doesn't really guarantee that the 'write' will be successful or that everything gets written to the disc. Bits could even be skipped in order to maintain a set speed. By definition it's actually setting the 'Streaming' flag in the 'Write (12)' CDB so errors might be / are ignored. (See MMC specs at www.t10.org for more info) When FastWrite is disabled the drive performs its own verification of the written data as it's written - hence it'll never say a write was ok unless it REALLY is ok. Streaming probably also stops it from reallocating bad sectors etc which would otherwise be taken care of automatically. So basically, unless you REALLY can't stand the additional time needed to burn the disc, I advise people to leave the FastWrite on the default setting of 'Disabled'.

If ImgBurn wouldn't accept the LB in the MDS file then it's because it splits the layers in a way that's not valid for OTP disc burning (i.e. L1 > L0)

Ok, here's another one based on the code I got from jeanl lastnight. (attachment removed)

Get yourself one of the Verbatim BD-RE discs and try that. Report back when you have and we'll take things from there.

Just exactly what files is this winfast thing creating? What are their names? If you're trying to burn a DVD Video disc then the 'structure' must be the same as the commercial discs you're saying it's totally different to.

Just that the sectors are readable.

I'm afraid not.

There is no offset stuff built into ImgBurn, hence the reason for ignoring CD-DA track content by default. It doesn't look at C2 values either. Stick with other tools if you're a hardcore audio enthusiast - at least until I get around to implementing anything offset related (assuming I ever do!).

No, write retries like that are never 'normal'. How is the writing surface of the disc? 100% finger print/dust free?

I'm more interested in the one with directshow overlays disabled - at least it rules that stuff out then! Just to get it straight though, when you 'seek' to a position (either via the buttons or the slider), does the preview window not show the correct frame? Then when you press play the frame goes from being 'right' to being 'wrong' (a squashed section of the screen as shown in your first pic) before then being 'right' again and displaying properly as per the bottom pic?

If it didn't work with a straight forward 'Read' and then 'Write', you're probably not supposed to be making backups of it. We won't help you with this any more, sorry.

I usually find the 'Print Screen' button works quite well That won't work when overlays are enabled though I wonder if the black screen isn't just it seeking to a decent start point. It lets you stop playback anywhere you like but it must search for something before playback begins. That might have something to do with syncing the audio? I no expert on the previewer or its code.

load graphedit and open the file via the 'File' menu.

That's probably just directshow's doing? Try turning the 'don't use overlays' option on in the setting and see if that's any better. As I mentioned previously, I'm stepping though this frame by frame in the capture and what you're describing isn't happening here. It sounds like it should be really obvious but it isn't to me.