Gear / Technical Help > Recording Media
fave cdr
voltronic:
--- Quote from: jb63 on June 19, 2020, 04:51:12 PM ---
--- Quote from: heathen on June 19, 2020, 01:15:28 PM ---
Friendly reminder about RAID and backups... http://www.petemarovichimages.com/2013/11/24/never-use-a-raid-as-your-backup-system/
--- End quote ---
this is the smartest thing I've ever read. It more than QUADRUPLES the cost of maintaining this stuff and I am pretty sure taping and archiving, esp. in 24/96, is a really expensive task.
--- End quote ---
Yeah, this is why I almost invested in a separate RAID setup, but never really went for it. It's an expensive addition for not much more peace of mind.
I haven't done it, but offsite backup is really the way to go in case of catastrophic failure. I set up a family member who doesn't know how to run local backups with Backblaze, and that works well.
WiFiJeff:
I have been using EAC in "Secure" mode and wondering whether just ripping in much faster "Burst" mode would suffice. It won't, for me at least.
Mostly if there are errors shown in secure mode they clear up if I use another drive to rip the problem tracks. In several cases this did not help, but doing a burst mode rip produced a file that played fine, I examine these burst mode tracks in iZotope to spot issues. But recently in some 2006 material I found two CDs with bad digi-glitch problems over four or five tracks that would not rip in secure mode but ripped in burst mode with only a "sync error" warning. I suspected perhaps equipment issues in the original recording, but... I had sent backups of these to a friend overseas (when postage was still reasonable for that), he ripped FLACs and sent them to me, they are perfectly fine. His copies were on fancy printed CD blanks (I was into photos as well as program listings) while my "masters" were on unprinted CDs with only Sharpie writing. The fancy printed CDs were all cloned from these now problematic masters.
I am now wondering whether "Secure" mode does in fact guarantee the files are good-as-new.
As if Covid were not making us all paranoid enough!
Jeff
DSatz:
WiFiJeff, the CD medium was invented for audio, and the CD-ROM format was built "on top of that". The audio CD format was designed to tolerate a certain amount of read errors. Audio CD players not only have error correction, but where that isn't possible, they go into error concealment modes (sample value interpolation or in extreme cases, sample value "holding") that generally fool most people's ears most of the time, and if the damage is so great that even error concealment can't be applied, they mute for a few milliseconds and go on.
But error concealment (which falsifies the data) is unacceptable for CD-ROM data retrieval; a single wrong bit in an executable file (if the CD-ROM was a software distribution disc) could crash the user's computer. So the CD-ROM format was designed with a considerable amount of additional, redundant data so that (a) even moderately severe disc damage still wouldn't cause any read errors, but just as importantly (b) the system would never allow a read error to "slip through" unnoticed--the hardware would always report such errors as failures. That way, incorrect data would never be read from the disc under the mistaken impression that it was correct data.
(By "never" I mean, with such a low probability that the odds were, it would never happen in many thousands of years with many, many users--although it's not completely, 100.00000000000% impossible; it would, however, require coincidences that are nearly unthinkable, like the same person winning the lottery jackpot every day for several months running type of thing.)
Anyway my point is, if you record .wav or flac files AS FILES rather than as audio tracks, the reliability of the system increases enormously--for all practical purposes, if you're able to read the files from the CD, you've got the right information. Whereas with audio discs there is a certain looseness, because it's well known that the ear is rather easily fooled up to a point. For example, in the cases where I had made two or three audio discs from the same set of WAV source files, sometimes EAC would extract the same wav files from some tracks on multiple discs, but not other tracks from the same discs. It has been rare that two audio CDs, both made from the same set of WAV files on the same recorder on the same day, have extracted exactly the same--even though EAC reports no errors, and if I extract the same tracks multiple times from either CD alone, I get consistent results for each disc--just not the same results from all (or both) the discs.
Moral of the story is, from an accuracy standpoint, audio CDs aren't as good for long-term storage as data CDs (or data DVD-Rs) that contain your wave audio as data, whether as uncompressed linear PCM or as FLAC files.
My apologies if you already knew all this stuff, but it's been a long time since it was new information that had to be thoroughly discussed, and I don't know whether you were around back then (1980s) or not.
--best regards
WiFiJeff:
I started recording on DAT in 1999 (my experience with computer files goes back to programming FORTRAN on punch cards when a computer was a large building). I started burning audio CDs because most people I know did not have DAT players, and I kept mostly making audio CDs as finished product until a late switch to archiving high resolution iZotoped files in 2015. When I left DAT for the Edirol R1 in 2005 (then Sony D1, D50, Sonosax Mini R82, reverting to Tascam DR 2D and DPA MMA-A when security got tighter), I also archived raw files, but re-editing these from DVD is way too daunting a project. So I am going back to the CD audio files 1999-2014 and ripping the audio files to hard drive. I have also archived (2015- now) finished (iZotope processed) high resolution files to BluRay storage, I used iZotope from 2009 on but stupidly did not archive the high resolution files right away.
I am saving the ripped stuff to three copies on USB hard drives (5 TB). I do not intend to burn BluRay discs of this older stuff, but I guess it wouldn't be hard to add that kind of backup once the project is finished.
Anyway, the number of problem CDs back to 2006 so far is manageable, but not zero. I just hope the more primitive CDs from earlier don't give greater problems. The bad errors I have gotten have sounded often like digi-glitched recordings, EAC burst mode has read the CD but gotten a file with noises and drop-outs that my early clones of the CDs sent abroad do not have. Even secure mode copies that finish but have reported errors are sometimes sounding okay but other times have digi-glitch sounding problems that were not originally there. The older Truesound Audio CD burns are sometimes like this as well; they played when new, then the bits melted away. Some very old ones are seen as blank, others have some tracks blank, others that play like noisy hell. None of mine so far that rotten.
Jeff
DSatz:
Continuing, and quite possibly concluding, my travelog: I am very nearly done transferring all the discs from the further caches that I'd squirreled away. I have again had problems with dual-layer discs, including four BD-Rs (total threatened loss, up to 46.6 GB per disc!).
But here's the thing I'd like to advise people (besides not entrusting ANY further data to ANY such discs): If you put a disc into the drive and the drive starts acting as if it's a blank disc, but you know that you've recorded on it and finalized the recording, wipe the disc off as well as you can and try again--several times if necessary. Eventually I was able to read and copy the data from all four discs, but not until I had passed through the valley of despair about them.
--best regards
[edited later to add this P.S.:] At least with the drive I'm using and Windows 10, the access pattern with dual-layer BD-Rs (Blu-Ray discs) makes them EXTREMELY slow when a large number of small files has to be copied from them. I'm currently copying a disc of archived work data that has hundreds of thousands of files on it including many that are just a few KB; I started it around 10 last night, left it running while I slept, and now twelve hours later it's still not done. "Time remaining" discouragingly says "More than 1 day", but I think that's because it's currently in the middle of several thousand small files, and has no way to know the mix of file sizes that remain (unless it were to average them ...).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version