LIGHTNING UK!

Yes, but how are you playing it? It's only really a fair test if you play it as a proper DVD Video disc, via a licensed player.

If you have a large (> 4.37GiB) ISO you need to burn, you'll have to buy some DVD+R DL discs. Splitting it won't work.

You've definitely extracted the track in RAW format yeah? I haven't messed with any options in my installation of IsoBuster (v4.1 pro). I extract the track by right clicking it and selecting as per the picture below... It doesn't look like my track is being extracted properly either, but it's not failing at the same offset yours is. So, I also get miscompares when using the IsoBuster extracted track, but in a different part of the sector. (Both of us are getting miscompares in the non-user data parts though, so it's not a massive deal) Verifying original disc against EAC+IsoBuster CUE/WAV/BIN.... ('Ignore CD-DA Data' option enabled) I then manually extracted the data track from ImgBurn's Read mode CUE/BIN using a hex editor and used that instead of IsoBuster's track. As you can see below, that worked fine and it compared just fine against the original CD-ROM without any miscompares. Verifying original disc against EAC+ImgBurn CUE/WAV/BIN.... ('Ignore CD-DA Data' option enabled) I've read that track off multiple times using IsoBuster and it comes back different (in the L-EC / PQ Parity region) every time. (EDIT: 5 reads, 4 unique bin files, 3 were wrong) I've read the disc multiple times in ImgBurn, extracted the data track in the hex editor and it's the same every time. Go figure! Peter/IsoBuster and I are using the same command for reading the sectors, so there's no reason for it to behave differently. Must just be another drive thing.

I'm sorry, I don't see your point. If 'of course' it verifies against the image file, surely it's correct? Unless your source image is wrong... but that's another problem. Assuming Session 2 is in the correct place (LBA wise - easy to check by looking at the disc/track information), there should be no problem and you should not be getting miscompares in the data track. Here I've read the original disc to a BIN/CUE and then verified said image against the original disc. Read It generated this CUE file CDTEXTFILE "PLEXTOR PX-891SAF PLUS 1.KC.cdt" TITLE "WHEATUS" PERFORMER "WHEATUS" REM DISCID 4996052000 REM UPC 5099749960527 FILE "PLEXTOR PX-891SAF PLUS 1.KC.bin" BINARY REM SESSION 01 TRACK 01 AUDIO TITLE "TRUFFLES" ISRC USSM10009008 INDEX 01 00:00:00 TRACK 02 AUDIO TITLE "SUNSHINE" ISRC USSM10009014 INDEX 01 02:10:20 TRACK 03 AUDIO TITLE "TEENAGE DIRTBAG" ISRC USSM10008431 INDEX 01 05:26:52 TRACK 04 AUDIO TITLE "A LITTLE RESPECT" ISRC USSM10009010 INDEX 01 09:28:27 TRACK 05 AUDIO TITLE "HUMP'EM N' DUMP'EM" ISRC USSM10009011 INDEX 01 12:47:67 TRACK 06 AUDIO TITLE "LEROY" ISRC USSM10009012 INDEX 01 16:25:60 TRACK 07 AUDIO TITLE "HEY, MR. BROWN" ISRC USSM10009013 INDEX 01 19:45:20 TRACK 08 AUDIO TITLE "LOVE IS A MUTT FROM HELL" ISRC USSM10009015 INDEX 01 21:55:27 TRACK 09 AUDIO TITLE "PUNK ASS BITCH" ISRC USSM10009017 INDEX 01 26:18:37 TRACK 10 AUDIO TITLE "WANNABE GANGSTAR" ISRC USSM10009018 INDEX 01 29:27:47 REM LEAD-OUT 33:13:28 REM SESSION 02 TRACK 11 MODE2/2352 INDEX 01 35:45:28 Verify So that's one option. Now I'll build my own CUE based on a CUE/WAV from EAC and the data track extracted using IsoBuster as a BIN. EAC EAC generated this CUE REM DATE 2000 REM DISCID 9F0B8D0B REM COMMENT "ExactAudioCopy v1.1" PERFORMER "Wheatus" TITLE "Wheatus" FILE "Wheatus - Wheatus.wav" WAVE TRACK 01 AUDIO TITLE "Truffles" PERFORMER "Wheatus" ISRC USSM10009008 INDEX 01 00:00:00 TRACK 02 AUDIO TITLE "Sunshine" PERFORMER "Wheatus" ISRC USSM10009014 INDEX 01 02:10:20 TRACK 03 AUDIO TITLE "Teenage Dirtbag" PERFORMER "Wheatus" ISRC USSM10008431 INDEX 01 05:26:52 TRACK 04 AUDIO TITLE "A Little Respect" PERFORMER "Wheatus" ISRC USSM10009010 INDEX 01 09:28:27 TRACK 05 AUDIO TITLE "Hump'em n' Dump'em" PERFORMER "Wheatus" ISRC USSM10009011 INDEX 01 12:47:67 TRACK 06 AUDIO TITLE "Leroy" PERFORMER "Wheatus" ISRC USSM10009012 INDEX 01 16:25:60 TRACK 07 AUDIO TITLE "Hey, Mr. Brown" PERFORMER "Wheatus" ISRC USSM10009013 INDEX 01 19:45:20 TRACK 08 AUDIO TITLE "Love Is a Mutt From Hell" PERFORMER "Wheatus" ISRC USSM10009015 INDEX 01 21:55:27 TRACK 09 AUDIO TITLE "Punk Ass Bitch" PERFORMER "Wheatus" ISRC USSM10009017 INDEX 01 26:18:37 TRACK 10 AUDIO TITLE "Wannabe Gangstar" PERFORMER "Wheatus" ISRC USSM10009018 INDEX 01 29:27:47 I've then extracted Track 11 (Session 2, Track 1) from the disc using IsoBuster. I've extracted it in RAW format and then renamed 'Track 11.iso' to 'Track 11.bin' (because .iso is wrong). Now I've modified EAC's CUE file so it includes session info and the data track, track 11 (in a 2nd session). REM DATE 2000 REM DISCID 9F0B8D0B REM COMMENT "ExactAudioCopy v1.1" PERFORMER "Wheatus" TITLE "Wheatus" REM SESSION 01 FILE "Wheatus - Wheatus.wav" WAVE TRACK 01 AUDIO TITLE "Truffles" PERFORMER "Wheatus" ISRC USSM10009008 INDEX 01 00:00:00 TRACK 02 AUDIO TITLE "Sunshine" PERFORMER "Wheatus" ISRC USSM10009014 INDEX 01 02:10:20 TRACK 03 AUDIO TITLE "Teenage Dirtbag" PERFORMER "Wheatus" ISRC USSM10008431 INDEX 01 05:26:52 TRACK 04 AUDIO TITLE "A Little Respect" PERFORMER "Wheatus" ISRC USSM10009010 INDEX 01 09:28:27 TRACK 05 AUDIO TITLE "Hump'em n' Dump'em" PERFORMER "Wheatus" ISRC USSM10009011 INDEX 01 12:47:67 TRACK 06 AUDIO TITLE "Leroy" PERFORMER "Wheatus" ISRC USSM10009012 INDEX 01 16:25:60 TRACK 07 AUDIO TITLE "Hey, Mr. Brown" PERFORMER "Wheatus" ISRC USSM10009013 INDEX 01 19:45:20 TRACK 08 AUDIO TITLE "Love Is a Mutt From Hell" PERFORMER "Wheatus" ISRC USSM10009015 INDEX 01 21:55:27 TRACK 09 AUDIO TITLE "Punk Ass Bitch" PERFORMER "Wheatus" ISRC USSM10009017 INDEX 01 26:18:37 TRACK 10 AUDIO TITLE "Wannabe Gangstar" PERFORMER "Wheatus" ISRC USSM10009018 INDEX 01 29:27:47 REM LEAD-OUT 33:13:28 REM SESSION 02 FILE "Track 11.bin" BINARY TRACK 11 MODE2/2352 INDEX 01 00:00:00 Attempting to verify this CUE/WAV/BIN against the original disc will fail with miscompares in the CDDA tracks. That's to be expected, you're comparing an image with read offset applied against what's being read from the disc without read offset. I'll now enable the 'Ignore CD-DA Data' option and try again. (See next post)

ImgBurn is a GUI app. There may well be other (actual 'command line') tools that'll do what you're after. You could also learn to write your own.

I'd imagine that's the only way to do it in ImgBurn. Of course anything outside of ImgBurn is also pretty much outside the scope of this forum.

I'm not really sure what to say about that. I believe you're just doing what I've attempted below, and it worked ok for me. I even reverted to the public 2.5.8.0 so we're on a level playing field. I took the WAV created by EAC, the BIN created by IsoBuster and then made a CUE using ImgBurn's 'Create CUE File' feature in the Tools menu. Admittedly, I had to fix a little bug first that prevented it from being able to parse the bin file properly and actually save the CUE. (Yes, I realise I've lost the actual track info and just treated the WAV as one long track ) CUE File REM SESSION 01 FILE "Wheatus - Wheatus.wav" WAVE REM FILE-DECODED-SIZE 33:13:28 TRACK 01 AUDIO INDEX 01 00:00:00 REM LEAD-OUT 33:13:28 REM SESSION 02 FILE "Track 11.bin" BINARY TRACK 02 MODE2/2352 INDEX 01 00:00:00 Write

The way to stop the 'the drive probably offset the audio samples' message from coming up in the log is to enable the 'Ignore CD-DA Data' option in the Settings on the Verify tab. It's enabled by default, so you must have disabled it. (EDIT: I see now that it continues to log that specific entry even after it's stopped logging miscompares due to there being too many - I've just fixed that) In the past (EDIT: and still true today with that Plextor), LiteOn (Mediatek chipset) drives have had an opposite write offset to read offset, therefore cancelling each other out and enabling pretty decent audio backups to be made with any software... and you can make copies of copies without an issue (the samples aren't offset more and more with each copy of a copy). In order for that to work, you need to be reading the disc in the LiteOn without any read offset applied (as would be the case if the disc is read in ImgBurn) and then burn the image without any write offset applied (as would be the case if burnt in ImgBurn). If you do it like that, you can disable the 'Ignore CD-DA Data' option so it actually checks for miscompares within those CDDA sectors (otherwise it just checks they're physically readable). Read - PLEXTOR PX-891SAF PLUS 1.KC Write - PLEXTOR PX-891SAF PLUS 1.KC Read - Optiarc DVD RW AD-5280S 1.Z8 Write - Optiarc DVD RW AD-5280S 1.Z8 Read - PIONEER BD-RW BDR-209M 1.34 Write - PIONEER BD-RW BDR-209M 1.34

Which kinda makes the whole ‘offset’ thing a bit of a waste of time. At some point, be it at the start or end of the disc, you’re missing real data and getting digital silence. It’s never going to be perfect. As I said before, it’s a fraction of a second. In the case of the liteon, it’s 6 samples / 24 bytes. 2352 bytes (1 sector) is 1/75th of a second, so 24 bytes is 0.000136054421769 seconds. Never in a million years will that make a difference.

I believe you can test reading leadin/leadout quite easily in ImgBurn itself. To test reading of the leadin, go into Read mode, open the sector viewer (disc icon in the Source box), tick the 'RAW' option and ensure it's on LBA 0. Now hit the back arrow button (LBA -1). To test reading of the leadout, still in the sector viewer, hit the disc icon on the left and it'll go to the last sector on the disc. Now hit the forward arrow button. Those two things will either work or give you an error. As you can see from the images, the Plextor doesn't support it.

The ‘liteon w’ isn’t actually a liteon at all, it’s based on optiarc technology. I’ve swapped out my ageing ‘ihas624 b’ for a newer model mediatek chipset drive. It’s badged as a plextor but really it’s very much a liteon and supports all of the advanced features they do - hypertuning etc. I’ve done 3 rips (of 10) so far for testing and it’s produced the same image each time... so it appears to be working as you’d expect a drive to. Sorry, I’ve no idea about overread stuff, it’s not something I’ve concerned myself with.

They're all just issuing the 'READ CD' command to the drive with a given lba start address and a transfer length. The drive should not be returning wildly different stuff - taking into account the lack of error correction. As we (the 3 non EAC tools you've mentioned) have to deal with data too, most will set the 'expected sector type' field within that 'READ CD' command to 'all types'. EAC sets it to 'CDDA'... perhaps that allows the drive to perform a little bit of sanity checking? (EDIT: Tested that by editing my code, it doesn't) There's nothing inherently wrong with what ImgBurn is doing (I haven't examined the other apps and therefore cannot speak for them), but yeah, the results from reading an Audio CD can differ every time. That may of course depend on the drive being used... each one behaves differently. (EDIT: It does, see below) In my testing, you might get an odd sector or two that have different data. That's enough to give you a large number of different 'samples' I guess, even though you're only actually talking about a fraction of a second. My 'LiteOn iHAS624 B GL2A' drive changes its mind on what it wants to return each time I read the disc I'm currently working with. Swap to my 'PIONEER BD-RW BDR-209M 1.34-ID60' and it returns a bit perfect copy of what EAC got from the LiteOn - with the exception of the offset stuff at the start/end of the disc. Make a 2nd image with the Pioneer and it matches the 1st one perfectly.

If the cdtextfile entry exists (and the file itself exists), it'll use info from that. If it doesn't, it'll use the strings in the cue file.

What you’ve done there is click on an advert and download something totally different.

Which mirror did you download it from?

No, only the volume label one is supported. The CLI options generally just manipulate the GUI settings, so if you've configured the GUI a certain way, it won't prompt you. There's no need for a CLI option. Don't forget, it's a GUI app, not a CLI one. I've just added basic support for a few CLI arguments.

Post the log please. The issue was probably completely unrelated. Screensavers shouldn't make a difference. So long as the drive isn't physically powered off or reset somehow, you can pretty much pause the burn and resume it without an issue - note, this is not something a screensaver would do anyway!

Isn't all of that just down to the offset correction stuff? ImgBurn makes no attempt to correct any of that stuff - EAC obviously does as that's specifically what it's designed for. Every drive has a specific offset it uses when reading, so although you would 2352 bytes of data to sector 0 or whatever, when you read them back you won't get the same 2352 bytes as the drive offsets where it reads from (something like that anyway!) Would a virtual drive really need an offset applied to it? I'd have expected it to have a read offset of 0 as it's just reading from a file. In any case, I very much doubt the differences are audible. If your drive returns different data each time it's asked to read the sectors (which are then written to the BIN), that's its problem I'm afraid - although obviously that does you no favours! There's no real error correction built into a CDDA sector, so it'll just return what it wants to return. All of that aside, weren't you just taking the tracks from EAC and adding the BIN you'd extracted with IsoBuster? How did that go or are you still waiting for some CD-R discs?

I believe CUE files were designed by GoldenHawk / CDRWIN people and I'm sure the first index in a file should be 00:00:00, so it looks like Nero is buggy/wrong. Fingers crossed, ImgBurn handles it differently (correctly!). There's a specific number of sectors between sessions and Nero doesn't seem to be honouring that. As a friendly tip/hint, don't extract to / name your file *.iso if you want MODE2/2352. *.iso should be reserved for MODE1/2048. Use *.BIN, even if it's just a file name extension that's different.

As part of the spec, there are often 2 second gaps inserted when you go between audio and data, or at the start of a session etc. So you aren't losing anything, it's just a forced pregap. You did right by trying IsoBuster, that's what I'd have told you to use. Don't set the index of the first track in that second session to 45:xx:xx though, the index is relative to the start of the file - and as you're starting a new file, you want it at 00:00:00

Since TY stopped manufacturing discs, I believe CMC bought their name/equipment/possibly manufacturing processs and that's what's now being sold under the CMC Pro name. I don't know if they're as good as the original / real thing, but hopefully they're better than their 'normal' stuff!

I'm afraid I don't have much to tell you. Matshita drives aren't very good at returning proper errors. Yours is simply saying 'No Write Current'... which means absolutely nothing to me. Taking it exactly as it is, obviously there is a write operation currently in progress, so what is it talking about?! I can only assume it has some sort of issue with the discs you're using. Try the other write speed it claims to support on those discs - i.e. 2x

Correct, just luck. In order to fit that much data on a disc, these devices inherently sensitive. Discrepancies in manufacturing, dust etc all play a part and I guess they're just more likely to fail to burn... for whatever reason. As you say, it would probably be cheaper and easier to just stick to single layer discs.

It makes no difference if you're burning files or an ISO. The data gets put into ImgBurn's buffer in the form of raw sector info and that's then sent to the drive, where it's stored in the internal cache and ultimately burnt to disc via internal processes. So the drive has complete control of the burn and just burns what it receives. It doesn't know or care about the original format... be it files or an ISO.

They’re different things. One says cycle and the other says eject. Cycling means it ejects and then loads. Eject means it ejects. The eject options apply after the entire operation has completed. Writer + verify operation is just classed as a write operation, not a verify operation. The cycling of the tray between write and verify actually forms part of the verification process... it checks the drive can reinitialise the disc. The eject after options are there for lazy users to save them ejecting the disc manually.