Title says it all. [Rant] After spending several hours researching, I've come up completely empty. One would think this should be a given in any program that burns images, but for cue/bin, this very simple, simple feature, is simply not to be found. Not in Nero, Alcohol, Recordnow, Blindwrite, UltraIso, ISOBuster, VCDEasy, (WinOnCD/DVD and InstantCopy don't do cue/bin at all), even damn CDRwin itself-- Is it just me or is that not insane? What's wrong with these authors? I know I can scan for read errors with many prgs (Nero CD Speed, etc), but that requires additional steps. BIG PIA when you have many cue/bins to burn.. And just because it's "readable", doesn't necessarily mean the data is correct. AFAIK, since the block size of VCD is larger than that for a data CD, you loose some error correcting info in exchange for more "space" on the CD (thereby 800MB on a 700MB CD), so you could have bit-errors which could lead to blocky or jumpy playback at times. There still is no program which will simply: Open a cue/bin file, burn it and automatically verify the burned CD versus the cue/bin image on the hard drive, the way many many programs (Nero, Recordnow, etc.) will burn an ISO (or img, etc.), then, if the option is selected, verify the CD. No user intervention required. Recordnow even goes one step further, and allows one to verify any CD/DVD to an existing image on the HD, which is great, since my NEC ND-2500a is a horrible reader, and reports read errors often on many discs (DVDs at least) it burns. Because of that, I don't even bother to verify images on the NEC (when burning DVD's). I burn them there, but place the disc into the DVD-Rom and choose "Only Verify", to verify them manually as a second step. I know this is not really what I said I wanted, but the 2500a is really a POS reader (at least for DVD's. Not sure w/CD's). (Actually, this all applies to mds/mdf files as well, since Alcohol has no verify option at all). If I can ever find a program which will conquer this obviously Herculean task, it will certainly be an instant hall of famer for me. sheesh. [/Rant] Why do I want this? So I can burn cue/bin's (and maybe mds/mdf's too) unattended. In my experience with various CD/DVD-ReWriters (Lite-On, NEC's, etc) and CD media, if burn-proof (etc) is activated for any reason at any time during an (S)VCD burn, that disc will invariably exhibit playback problems (as stated above). So, to be 100% sure the CD burned 100% correctly, I am forced to sit there and stare at the light to be sure burn-proof never was activated throughout the burn, since of course, no burning prg I'm aware of will tell you if burn-proof was activated during a burning session. Surely others must be experiencing this as well. TIA
This is very strange. Are you sure the disc isn't protected? It's strange that no program work and, more, such programs usually abort whan a 'Record Image' has errors (for example, in Alcohol 120% you can select 'delete image file after recording' and this is NOT done if during the record there's a problem bacause an error message appears and stops all). Try to 'mount' the image with Alcohol and scan it with Clony XXL o A-Ray Scanner. What do they say?
Not really that strange. If you select to use burn-proof and thh drive detects and under/overflow, the writing laser is momentarily turned off to wait for the problem to be alleviated. While that's fine for data CDs (because of error correcting info stored on the disc), this causes problems with VCD's since that error info is used as actual data as I said in the OP. There's nothing protected on wrong with the images. I mount with Alcohol before hand and view or virus check them (whichever is appropriate).
If the .cue file(s) can successfully be extracted with programs like IsoBuster or CDMage, then this alone is "verification" that the files are good. I've never had any problems whatsoever burning bin and cue using burnatonce. On occasion, the .cue file is corrupt, so I use Cue Creator and create a new .cue file. Nero does support burning bin and cue file format.
======== If the .cue file(s) can successfully be extracted with programs like IsoBuster or CDMage, then this alone is "verification" that the files are good. I've never had any problems whatsoever burning bin and cue using burnatonce. On occasion, the .cue file is corrupt, so I use Cue Creator and create a new .cue file. Nero does support burning bin and cue file format. ========= I dont think you understand what I'm saying. There is nothing wrong with the cue/bin files themselves on the HD of course. The problem is I want the burnning app to verify that the disc just burned has had the cue/bin correctly written to its surface, thus the verify option, which will compare the contents of the bin file on the HD to the data on the newly burned CD.
The verify option in Nero will compare the two bit for bit, is this not satisfactory? It seems the problem is more the fact that your NEC is a crappy reader than it is a shortcoming of the software makers. I can't imagine there's any incentive for someone to write a particular piece of software just for folks who have a crappy reader. What are you doing to make burn proof activate when writing from the HD? There is something seriously wrong if burn proof gets activated during a write from the hard drive. The transfer speeds from the hard drive to the burner are waaay more than enough to keep the buffers full when the hardware and settings are configured properly.
This would be perfect- IF Nero had verify for cue/bin images-- like it does for other CD image formats. Alas, for some incomprehensable reason, it does not, thereby, my frustration espoused in the OP. No argument here. I feel there is. The Nec being a shit reader has nothing to do with the subject; Verify for cue/bin is all I'm seeking. Any mildly intensive operation such as quickpar-fix, or unrar (especially those ops which affect disk) will cause BUP to activate, and this isn't just my specific scenario/setup. It is common on all "standard" setups (not withstanding special sets, such as RAIDS or mixed SCSI-IDE setpus). I've had it happen on multiple OS incarnations with multiple setups of my own, from LiteON CDRWs to Plextor CDRWs on multiple machines of varying substantial CPU power-- and on other peoples setups as well. People usually dont notice BUP activate, and when they see a disruption upon VCD playback often this is why. Data CDs arent affected by BUP for reasons I stated in the OP.
Nope. Not if the user has any sense about what they're doing. Executing disk intensive operations during a burn and then complaining about BUP kicking in is ridiculous. Maybe it's just me but I don't understand the need for an app to verify the burn afterward when a logical change in methods would mitigate the need for the app entirely and ultimately save time.
Becasue occassionally BUP will activate when you don't realize it (the OS could decide to do some intensive op for a few moments in the background for whatever reason). I wasn't suggesting that I do such intensive disk op's (rar, etc) while I'm burning, I don't. I was merely giving an obvious example. There are many other reasons that could cause OS activity to suddenly "pick-up" that would interefere with the burn, and when doing unattended burns of VCDs, how would you know if the BUP came on. Verifying is a fantastic way to rectify that situation and give more confidence in the burn. I suppose if s/w writers didn't think so then they wouldn't have the option there at all, yet it is. The question is, is there some underlying reason why it's absent for cue/bin.?
Thx. I will check this one out, although the main idea is to have the copy/verify under one-roof, one op.
Are you implying that no burning program "verifies" bin& cue write, but not other file formats? Why make such a big fuss over spilt beans m8? I've been burning bin& cue file format for 7 years and my "verify" write success is at least 99.9% accurate.
I have yet to find a prg that verifies a cue/bin burn to the image on the HD after it has burned the CD.
jimboe, I challenge you to use burnatonce, a free burning program and write any iso file then write a bin and cue file. You get the same results. burnatonce http://www.burnatonce.com/downloads Obviousy you would use IsoBuster>extract to your hd to "verify" that the written data of the burned cd is correctly written. One can do the same for a written ISO, data, music. (so forth and so on) _X_X_X_X_X_[small]MSI KT6V-LSR MS-7021 AMD Athlon XP 2500+ (OC'd to 3200+) 1 Gig Corsair XMS PC3200 (OC'd DDR 400) MSI MS Starforce nVidia GeForce FX5500(256 DDR) Maxtor ATA\133 200 gig Lite-ON LTD165H DVD-ROM Lite-ON LDW411S DVD-Burner[/small]
This alone doesn't verify the contents of the disc. This verifies that the disc can be successfully read all the way through, not what I'm after. Continuing along your above suggestion, I would then have to use some sort of file comparison utility (MSDOS fc would work) to compare the .bin I just created with the original .bin I previously burned the disc from. Yes. That would of course work, but the intent of my OP was to find a prg which essentially does this in one step, by itself, without user intervention, and without recreating the .bin file on the HD from the newly burned disc. I do this now all the time by selecting "Record and verify" in RecordnowDX for all images *but* cue/bin, since it doesn't support cue/bin.
Record and verify isn't substantial proof that what you burned is verification that the data is good. The only way anyone knows is to simply take what one burned, insert in a "rom", O\S recognizes the written data m8.
Yes but the circuitry means that the laser will reactivate exactly the area after the it was turned off. While it does not support burning directly BINs, it DOES support BIN and CUE images I thought the verification was sector by sector. Welll I wouldnt go so far as to say seriously wrong... . You ever try burning on a laptop? Firstly the verification is done sector by sector and secondly the CD image format shouldnt be the determining factor...... Indeed, developers cannot make a program based simply on a single drive ... well they could but that would be bad programming wtf? Not a chance -- if it was so "ridiculous" then why is it such a major feature? Not everyone has a super-uber that can withstand even the simple task of playing MP3s and burning at 8X simultaneously. Note that the drive speed is inconsequential since the maximum transfer rate (which never happens as you and I both know) to and from a burner is 33MB/s, factor in burn speed and realistic HDD transfer speeds than its quite easy to see that BUP is a neccessity -- and an effective one. Because "changing methods" does NOT absolutely guarantee that the CD is written properly because there is always a possibility of something happneing wrong during that process. The simple fact that drives have C1 errors regardless is a testiment to this. Unfortunately, 99.9% sometimes isnt good enough. That verification (along with the technique I suggested) would "prove" (even though it doesnt, it only gives 99.9% surity if even) that the extraction is successful or that the read is successful -- not that the burn is done absolutely, 100% without a shadow or even remotest potential of contradiction, done properly. Not absolute proof..... Agree entirely on the first point but the fact that the OS reads the disc isnt absolute proof either (and quite possibly less reliable) == THREAD REOPENED == (i sincerely hope........) jimboe If you are looking for absolute 100% verification type of things then unfortunately I must suggest that your search is an unfeasible one as, at least for the consumer market, there isnt really a feasible implementation (mostly because 1. there isnt a market/demand for it and 2. the sheer number of different types of drives). Anything you find that gives you absolute trust (or even relative absolute trust) would have to be specifically coded for whatever you are doing and specifcally for your configuration. Any implementation of such an absolute verification would be more of a hardware implementation rather than a software one. You are definitely lookin at bit-by-bit scanning there (something ive been lookin into but simply cant afford ) If you are concerned about the BUP thingy -- dont forget you can disable it. That would allow you to narrow down the possibility of the BUP causing jitter or whatnot (which i dont suspect is the problem even to start with). Another approach would be to do a image-check before hand and then make an image afterwards and do a comparison ,... of course you insert a crapload of uncertaintly in the image-making but that might actually be a good thing as it factors in unpredictability of different drives etc
Bingo. Precisely as I've been saying... Why do you think it is not absolute proof? My understanding is that Recordnow is reading the data off the CD (whether bit-by-bit or sector-by-sector) and checking whether that "portion" of data read matches what is in the image file on the HD. If each "portion" matches all the way throught the entire CD, then the CD (at least on that read-back) is 100% correct. Sure, the CD could physically degrade at some later point but that's not all that common. If I've successfully passed verify in the above manner, I have high confidence that I can read that CD back 100% correctly, at least in the drive which performed the verify, if nowhere else. Good enough for me. Well I'm quite satisfied with Recordnow, it does exactly what I want; except for of course cue/bin And although I'm sure you already realize this, I'm not after 100% in the sense of "forever". As I said, media can degrade after time.. Disabling BUP is a possibility. Image checks before and after would have the same net result as the verify I do now with Recordnow, only it would require more intervention and time, but it would work. It's too bad that versions newer than 4.6 of Recordnow have been "dumbed down" and take away most control from the user. The really great thing about Recordnow is that even though the NEC is a sub-par reader, I can make a burn, and throw the disc into the DVD-ROM (far better reader) and select "Only verify" if need be. Of course that removes the "one-step"edness which I seek, but I ussually don't have problems verifying in the NEC. Hear me out here and tell me if this makes logical sense to you. My thoughts on the feasability are this. Even though there are so many different drives of varying read quality, the bottom line really is, if I verify successfully on any said drive, then that's basically a 100% good copy (at least that can be read back on that drive). Why? What do you think the odds are of getting a "false positive" (so-to-speak) in this situation? I would think they're pretty astronomical. Now getting a verify failure when the disc may actually be good (the "false-negative"), that's not so unfeasable. IMHO, the latter is the only reason I can see programmers using as an excuse not to implement a verify, but I don't think it's really a compelling one-- especially in light of the fact that some of the same programs already have a verify option for other burning jobs (such as mastering and what not). Here's my current kludge. I'm now mounting the cue/bin with alochol, and doing disc-disc "Record and verify" with Recordnow, and that seems to work fairly well. It may be about as "one-step" as I'm going to get.
