Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Bit Error Correction for CD Track Ripping/Saving & File Backups? (Read 8399 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Bit Error Correction for CD Track Ripping/Saving & File Backups?

While likely unable to converse at the full knowledge level of many here, I know enough about the binary coded structure of data to see how badly it can impact audio quality, however imperceptibly. To maximize my protection from these losses, I was fortunate to see this article  https://arstechnica.com/gadgets/2021/01/linus-torvalds-blames-intel-for-lack-of-ecc-ram-in-consumer-pcs/

which led me here https://www.gearslutz.com/board/music-computers/386294-ecc-vs-non-ecc-memory.html

and now here https://hydrogenaud.io/index.php?PHPSESSID=7b5egpokpkeennhlb6et8mnim0&topic=111995.75  
where Chronosphere said
Quote from: ChronoSphere on
So yes, there are separate programs that not only let you detect but also repair the damage at the cost of additional space used.

Could you please recommend which data integrity and bit correcting programs are currently the best and easiest to use for non-coders and other dummies?

And would use of this software obviate switching to a computer using ECC memory?

OTOH, would using the recommended error detection/correction software with, say, a Xeon Rocket Lake cpu and ECC memory supportive motherboard desktop pc give the best chances for file restoration and future protection against bit rotting of uncompressed WAV files of CD track rips? 

And speaking of uncompressed WAV files, is there any reason not to use this format for storing CD track rips if preserving sound quality is top priority? 

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #1 –
You can get errors when ripping CDs and AccurateRip can help to detect any errors.    CUETools can sometimes repair a bad rip.   The error checking & correction on audio CDs is not as good as on hard drives, and not as good as WAV or other computer files burned onto a CD.
 
Other than that, how often have you REALLY seen data corruption on your computer?   Usually when it happens it's a bad hard drive and it's usually badly corrupted, not just a bit here-or-there.

...This text is going all over the world through countless connections and if there's a spelling error you can sure it's my error and not corrupted data.  ;)

Quote
And speaking of uncompressed WAV files, is there any reason not to use this format for storing CD track rips if preserving sound quality is top priority?
FLAC (or ALAC) is lossless compression and you get files about half the size.     FLAC also has a built-in checksum so you can know if it does get corrupted,   Metadata is poorly supported and poorly standardized for WAV.

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #2 –
Quote from: nmxny24 on
Could you please recommend which data integrity and bit correcting programs are currently the best and easiest to use for non-coders and other dummies?
Sure, as this is about "memory", not to be mistaken for HD or SSD, make your files "read only" so they never ever will be edited and exposed to the thru abhorrence  of none ECC memory!
Alternative: ever encountered this problem in real live?



TheWellTemperedComputer.com

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #3 –
Quote from: nmxny24 on
Could you please recommend which data integrity and bit correcting programs are currently the best and easiest to use for non-coders and other dummies?
MultiPar was mentioned in that thread, and I second the recommendation. It's one of the best parchive programs out there and is still actively developed. You'll probably need to spend some time to familiarize yourself with it, but once you do it all makes sense.

Quote
And would use of this software obviate switching to a computer using ECC memory?
Well, not entirely, ECC still has some value. But here's the thing:
1. RAM is not the only source of corruption. IME the main one are faulty hard drives. And other components (CPU, mobo...) can also be responsible.
2. When RAM is the cause of corruption, it's not necessarily because of the lack of ECC, but simply because it's faulty or it's running at unstable settings—in fact, I'd say that's the case the vast majority of the time, at least with fast "gaming" RAM, which is popular with PC builders. That's why you should always run some proper stress tests.

And in general, if you're paranoid about data integrity, you should learn the various ways of using checksums. Some audio formats (like FLAC) include a checksum of the audio data by default, but you can use external methods too. Total Commander, if you use it, integrates this functionality pretty well.


Quote from: DVDdoug on
Other than that, how often have you REALLY seen data corruption on your computer?   Usually when it happens it's a bad hard drive and it's usually badly corrupted, not just a bit here-or-there.
I've had some more subtle and mysterious file corruptions as well. I believe it was a case of a bad HDD, but there was no indication of that from the SMART data or from the HDD checking tools.

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #4 –
* You need backup anyway.

* If you want redundance, then RAID is the thing. The typical hard drive failure is a drive crash, not a random bitflip.
Look into a file server with ZFS or Btrfs.
Note, RAID is about accessibility, not about protection against "WTF DID I JUST DO?", nor about theft, and rebuilding an array of big drives will leave you backupless for days - so it is a complement to an off-site backup, not a substitute.

* With a checksummed lossless format - choose FLAC or possibly WavPack, avoid ALAC! - you can verify integrity.


(I have had loss of partial files. That was settings from back in the day when Windows defaulted to thinking that an NTFS drive must be internal, and so it employed drive caching when the file system was NTFS ... and then write data got lost when my mobo dropped the USB connection. But apart from that ... only when a drive was about to go totally titsup.)

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #5 –
Quote from: Porcus on
* If you want redundance, then RAID is the thing. The typical hard drive failure is a drive crash, not a random bitflip. Look into a file server with ZFS or Btrfs.
Note, RAID is about accessibility, not about protection against "WTF DID I JUST DO?", nor about theft, and rebuilding an array of big drives will leave you backupless for days - so it is a complement to an off-site backup, not a substitute.

* With a checksummed lossless format - choose FLAC or possibly WavPack, avoid ALAC! - you can verify integrity.


(I have had loss of partial files. That was settings from back in the day when Windows defaulted to thinking that an NTFS drive must be internal, and so it employed drive caching when the file system was NTFS ... and then write data got lost when my mobo dropped the USB connection. But apart from that ... only when a drive was about to go totally titsup.)
ZFS or Btrfs……?? WTF? No way could I have time to get my head around any of this.  https://www.google.com/search?q=file+server+ZFS+Btrfs&rlz=1C1CHBD_enUS825US825&sxsrf=ALeKk00NPXxpDqGTwRp2k3np_1M5j_T5YA:1613345085019&source=lnms&tbm=isch&sa=X&ved=2ahUKEwjr2MTlwuruAhUwhOAKHYWVDCsQ_AUoA3oECBUQBQ&cshid=1613345089008926&biw=819&bih=500&dpr=1.25

Big LOL, but my “for dummies” redundant backup system comprises two old desktops each with 1TB HDD storage drive and an external enclosure with two 500GB drives. It’s obviously the ultimate in awkwardness and doesn’t offer off-site protection, but it’s cheap and essentially idiot proof. And with the HDDs being in separate systems there’s considerable insurance against catastrophic data loss. It’s not for lack of funds, but as explained below I’m just too ignorant, busy earning a living and involved with completing critical and badly overdue projects to install a safer and/or more user friendly backup solution. 

[/quote]
Quote from: Brand on

MultiPar was mentioned in that thread, and I second the recommendation. It's one of the best parchive programs out there and is still actively developed. You'll probably need to spend some time to familiarize yourself with it, but once you do it all makes sense.

Quote
And would use of this software obviate switching to a computer using ECC memory?
Well, not entirely, ECC still has some value. But here's the thing: 1. RAM is not the only source of corruption. IME the main one are faulty hard drives. And other components (CPU, mobo...) can also be responsible.
2. When RAM is the cause of corruption, it's not necessarily because of the lack of ECC, but simply because it's faulty or it's running at unstable settings—in fact, I'd say that's the case the vast majority of the time, at least with fast "gaming" RAM, which is popular with PC builders. That's why you should always run some proper stress tests.

And in general, if you're paranoid about data integrity, you should learn the various ways of using checksums. Some audio formats (like FLAC) include a checksum of the audio data by default, but you can use external methods too. Total Commander, if you use it, integrates this functionality pretty well.


Quote from: DVDdoug on
Other than that, how often have you REALLY seen data corruption on your computer?   Usually when it happens it's a bad hard drive and it's usually badly corrupted, not just a bit here-or-there.
I've had some more subtle and mysterious file corruptions as well. I believe it was a case of a bad HDD, but there was no indication of that from the SMART data or from the HDD checking tools.
Thanks for these cautionary reminders and suggested testing beds. The last poster in this thread also suggested MemTest5 for RAM integrity testing. https://www.gearslutz.com/board/music-computers/386294-ecc-vs-non-ecc-memory-2.html#post15293885
 
Indeed, what’s sad regarding your highly recommended Multipar app, is that glancing at what’s said here https://en.wikipedia.org/wiki/Parchive tells me that as I know little more than this https://en.wikipedia.org/wiki/File_system I’m really wasting everyone’s time here. I’m hoping that I can learn enough more to at least run RAM tests and evaluate system error logs, which I never thought pertained to audio related errors, or that the info would be intelligible to the less rigorously trained Windows user to make use of for correcting/preventing such errors. The last extensive formal technology training I had was long ago in a Long Island technical school where I was in the top seven out of class of class of 40 studying analog and digital circuits and systems for >> 25 hours a week for ten months. But we never studied even basic file systems or anything to do with software design. 

But in addition to the hopefully doable RAM testing, it would seem at least as useful to reconsider the other possible causes and kinds of errors impacting audio quality, which I know or can learn enough more to check for. For example, like most here, this guy saves CD rips to FLAC also. https://jens-ingo.all2all.org/archives/1900

But I must have ripped at least 80 CD tracks to uncompressed WAV files and I’ve never experienced the kinds of errors he had.
 
However, are there other kinds of audio quality losses that can occur due to bit flips? For example, while the DAC in my old ASUS sound card may limit my aural detection of this, how likely can bit errors not cause crashes or other big problems but can cause gradual or even sudden loss in audio resolution and other damage in WAV or FLAC files?

And while possible with any RAM, can resolution loss be more likely to happen in non-ECC RAM pcs?

Also, whether saving rips to WAV or FLAC, as Rosval suggests here
https://hydrogenaud.io/index.php?topic=120576.new#info_993800 there will be no chance of any data corruption
if the file is saved as read only? 

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #6 –
RAM does not usually go bad during its life, but could be manufactured defective. Test it once with a boot CD after assembling or upgrading a PC and don't worry about it anymore. You would get checksum errors that appear and disappear randomly, and affect different files each time, with non-audio applications, such as extraction from compressed archives. Programs would crash if, by chance, the error happened in executed code and not data. An error from bad RAM will not be detected and would propagate when a file is copied unless there is a checksum at the application level, while an error on a hard drive or CD will be reported with a message or a long pause.

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #7 –
Quote from: nmxny24 on
ZFS or Btrfs……?? WTF? No way could I have time to get my head around any of this.
Whether or not https://www.windowscentral.com/how-to-set-up-freenas-home-file-server is a too high hurdle, you still need backup to secure against hard drive failure. Let's get real here: you have picked an obsession with a very rare fault that would usually just make an application crash upon playback and at worst corrupts a file as it is written and filled with faulty data. You should be more concerned with a more common fault that crashes an entire collection.

File-level redundancy is good for near-complete torrent downloads, not for hard drive crashes.
If you are adamant about that sort of errors, then
(1) get the bytes written correctly to disk in the first place (that goes for all of us, but archive-level redundancy does not help, it will protect the wrong data)
(2) never overwrite audio files. Oh, and turn off all sorts of drive defrag.

The solutions to (1) are as follows:
* If you rip CD's, have CUETools verify your rips afterwards. If they verify against an external database, then the audio as written to drive, was correct.
* If you buy downloads, verify integrity upon download.

Concerning (2):
With foobar2000 and one of the external tags components - I use http://www.foobar2000.org/components/view/foo_external_tags - then retagging will not write to the actual media file.
Should there be a wrong bit calculated and hence written to drive, it will only botch up song titles or other metadata - not your actual audio. You can also copy the metadata files to your backup without overwriting the audio.
Cons: you get a foobar2000 only solution, and you cannot manually move or rename files.


For "permanent" backup drives, you can parity protect the entire drive (or partition). One solution I used in the past was https://www.vilett.com/disparity/ (unsupported, since the author's untimely passing); select a third 500 GB drive as dedicated parity drive, fill it, and then verify - if you had an arbitrary bit wrong, it will yell at you just like an archive integrity verification would.


And as for off-site backup: if you have an office at work, then just make an extra drive copy and bring it there.

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #8 –
Quote from: nmxny24 on
Indeed, what’s sad regarding your highly recommended Multipar app, is that glancing at what’s said here https://en.wikipedia.org/wiki/Parchive tells me that as I know little more than this...
Here's a short summary of how Multipar (or a similar parchive app) works:
1. Take some files you care about (aka source files).
2. Create par2 files, as much as you want, as a % of the source files size (the bigger the %, the more damage you'll be able to recover).
3. If some corruption of the source files occurs, you can use those par2 files to fix it.
That's it, the rest are just details. Create a test folder and play around with it, "corrupt" some files on purpose and recover them to see how it works.

But as Pictus said, first make sure whatever you have (from what I understand you have CD rips in WAV format) is actually properly ripped in the first place. CueTools can contact the AccurateRip and CTDB databases online to compare your files to those of other people. EAC can also do this when you rip a CD. And using FLAC instead of WAV, while not strictly necessary, will make things easier in the long run.
Then make some copies (and checksums).
Then start to worry about par files and ECC RAM.

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #9 –
Quote from: Porcus on
You should be more concerned with a more common fault that crashes an entire collection.

File-level redundancy is good for near-complete torrent downloads, not for hard drive crashes.
If you are adamant about that sort of errors, then
(1) get the bytes written correctly to disk in the first place (that goes for all of us, but archive-level redundancy does not help, it will protect the wrong data)
(2) never overwrite audio files. Oh, and turn off all sorts of drive defrag.

The solutions to (1) are as follows: * If you rip CD's, have CUETools verify your rips afterwards. If they verify against an external database, then the audio as written to drive, was correct.
* If you buy downloads, verify integrity upon download. and bring it there. 
I don't get it. You seem to say that backing up on to a few HDDs doesn't make sense or is somehow bad. My understanding is that HDDs have very good error protection. So as long as you're not backing up files (document files NOT a/v files) with updated files that did not somehow get corrupted, why wouldn't you want to have a few HDDs with the same data in case on or more drives die?

And defragging HDDs, where you store WAV and mp4 files, is a bad practice? If doing so can corrupt data then how?

And won't a badly fragmented HDD not only take longer to find the data to play the A/V file but will eventually become consequently error prone, even if it doesn't begin to corrupt data by being so fragmented?

    

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #10 –
Quote from: nmxny24 on
I don't get it. You seem to say that backing up on to a few HDDs doesn't make sense or is somehow bad.
??? No? I've been clear that you need backup, and I've even advocated redundance there.

Quote
My understanding is that HDDs have very good error protection.
Oh?

Face it, a HDD provides zero protection against you writing the wrong bits onto them. If you have an error in your audio, then your HDD has faithfully written that into your .wav file (... why even use .wav? It has no integrity check!). If you put your .wav file into an archive file, the HDD will faithfully write your .wav file with the faulty audio into an archive. If you build redundance to protect your faulty bits, the hard drive will faithfully write the bits that protect your wrong bits. Not protect it.

The big hardware issue - not talking user errors here! - is how (spinning) drives have a limited lifetime, and when they fail, they often fail abruptly in a crash that makes the entire drive unreadable - at least by normal means. You might have to pay a forensic company biggg $$$$s.


Quote
And defragging HDDs, where you store WAV and mp4 files, is a bad practice? If doing so can corrupt data then how?
If you read from disk and write back on disk, where do you think the bits reside? In RAM or somewhere else?

No, it is not much of a problem - because you were wrong at the outset, making a bigger fuss about the smaller problem.

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #11 –
Quote from: Porcus on
Quote from: nmxny24 on
I don't get it. You seem to say that backing up on to a few HDDs doesn't make sense or is somehow bad.
??? No? I've been clear that you need backup, and I've even advocated redundance there.
Quote


My understanding is that HDDs have very good error protection.
Oh? Face it, a HDD provides zero protection against you writing the wrong bits onto them. If you have an error in your audio, then your HDD has faithfully written that into your .wav file (... why even use .wav? It has no integrity check!). If you put your .wav file into an archive file, the HDD will faithfully write your .wav file with the faulty audio into an archive. If you build redundance to protect your faulty bits, the hard drive will faithfully write the bits that protect your wrong bits. Not protect it.
Of course I see that you're strongly suggested redundancy.  But rather than my "bunch of HDDs' backup system-which you point out cannot check integrity between the original backed file and the latest version I'm about to overwrite it with-you're saying that ZFS or Btrfs redundant systems are the only safe way to go. But who would build it for me? https://www.microcenter.com/search/builds.aspx  How much would it cost? Would it be cloud-based and/or would I have to buy a lease or pay a monthly fee? I REALLY could do without another utility bill!!
Quote from: Porcus on
The big hardware issue - not talking user errors here! - is how (spinning) drives have a limited lifetime, and when they fail, they often fail abruptly in a crash that makes the entire drive unreadable - at least by normal means. You might have to pay a forensic company biggg $$$$s.
So this ZFS or Btrf file integrity check backup system you suggest using doesn't use HDDs-certainly not SSDs?  

Quote
And defragging HDDs, where you store WAV and mp4 files, is a bad practice? If doing so can corrupt data then how?
Quote from: Porcus on
If you read from disk and write back on disk, where do you think the bits reside? In RAM or somewhere else? No, it is not much of a problem - because you were wrong at the outset, making a bigger fuss about the smaller problem.
Okay, makes sense, especially as there's nothing to protect the data during the read/write/read bursts during the defragging. Of course, no one with half a brain would defrag an SSD (system or storage drive). I didn't notice much faster access time when I was defragging storage drives anyway. But are you also saying that a late model computer build with reasonably fast CPU and ample RAM can still find the files on the SDD system and HDD storage drive quickly even after 5 years or more of continual fragmentation?

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #12 –
No ... back to square one.

You should address the risk factors by chance and consequence. The biggest risks once the data is on your computer, are drive crash, and "WTF DID I JUST DO?!" - not RAM faults. Use backup. Keep a backup and an off-site backup. If you have as little as a TB, then an extra USB drive is comparably cheap.

In the rare event that your RAM chip flips a bit when you are reading from CD, that error will be safely committed to disk. If you try to put it in a parity-protected archive, then the error will be protected by the extra bits. Yes it will scream error if a bit was flipped during the unnecessary operations of processing the archive for writing, but there are easier ways.

What you should do - and the first part here is CD specific - is to
* Rip with AccurateRip verification. You want the bytes correct in the first place. I might remember wrong, but I think EAC verifies after writing to HDD. In any case, if you kept EAC logs - or cuesheets, or the appropriate tags - then CUETools can retro-verify. Also this software from the creator of AccurateRip, can do that.
* Rip to FLAC (or possibly WavPack). They are checksummed formats, and can check the integrity of the audio data. .wav offers nothing such. True, compressing to FLAC or WavPack means everything goes by way of RAM, but you can bit-compare the .wav audio with the FLAC audio before deleting the .wav files. You should.

Now once all this is in place, you can verify audio integrity. If a file fails verification, then (1) try once more (different result --> question your RAM); (2) check from your backup drive (different result --> question your hard drive; same faulty result but different from when you initially verified --> question everything).

The following are less of a problem, as memory is usually reliable. However if you choose not to trust your RAM, you cannot trust these operations either:
* Retagging might prompt rewrite of full file to drive. Then it is read from drive, stored in RAM, written to drive. If you want to avoid this, use external metadata as I've pointed out earlier. Cons: you will get a foobar2000-only solution for your updated metadata. Of course, a corruption might corrupt those files, but your audio will be intact.
* Defragmentation will mean a file is read to RAM before written to a different place in the drive. The very same considerations as for rewrite by retagging apply: it is generally no problem, however you have made it one if you don't trust RAM.

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #13 –
What Porcus said, from the beginning.

Ditching Windows (which to me is a further step towards protecting your data, albeit not a mandatory one) you can have Btrfs or ZFS on your workstation pretty easily (a point-and-click choice upon installation), just check out openSUSE or GhostBSD.

In regards to backups why not invest in a small home NAS like these?

Then ripping with a tool which supports AccurateRip (I use Whipper) and to a lossless checksummed format (WavPack for me) is the final step.
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #14 –
Quote from: DARcode on
What Porcus said, from the beginning.

Ditching Windows (which to me is a further step towards protecting your data, albeit not a mandatory one) you can have Btrfs or ZFS on your workstation pretty easily (a point-and-click choice upon installation), just check out openSUSE or GhostBSD.

In regards to backups why not invest in a small home NAS like these?

Then ripping with a tool which supports AccurateRip (I use Whipper) and to a lossless checksummed format (WavPack for me) is the final step.
Thanks. Maybe something like this https://www.qnap.com/en/product/ts-451%2B as long as fan noise levels aren’t objectionably highly before I’d get around to installing it in another room and routing data between it and my pc.

I didn’t finishing viewing the voluminous specs and features of those Qnap models, but how does Qnap error prevention and/or alerting during backups compare with that of ZFS or Btrfs, which are evidently the SOTA in error minimizing redundant backup systems?

 

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #15 –
Quote from: Porcus on
No ... back to square one.

You should address the risk factors by chance and consequence. The biggest risks once the data is on your computer, are drive crash, and "WTF DID I JUST DO?!" - not RAM faults. Use backup. Keep a backup and an off-site backup. If you have as little as a TB, then an extra USB drive is comparably cheap.

In the rare event that your RAM chip flips a bit when you are reading from CD, that error will be safely committed to disk. If you try to put it in a parity-protected archive, then the error will be protected by the extra bits. Yes it will scream error if a bit was flipped during the unnecessary operations of processing the archive for writing, but there are easier ways.

What you should do - and the first part here is CD specific - is to * Rip with AccurateRip verification. You want the bytes correct in the first place. I might remember wrong, but I think EAC verifies after writing to HDD. In any case, if you kept EAC logs - or cuesheets, or the appropriate tags - then CUETools can retro-verify. Also this software from the creator of AccurateRip, can do that.

* Rip to FLAC (or possibly WavPack). They are checksummed formats, and can check the integrity of the audio data. .wav offers nothing such. True, compressing to FLAC or WavPack means everything goes by way of RAM, but you can bit-compare the .wav audio with the FLAC audio before deleting the .wav files. You should.

Now once all this is in place, you can verify audio integrity. If a file fails verification, then (1) try once more (different result --> question your RAM); (2) check from your backup drive (different result --> question your hard drive; same faulty result but different from when you initially verified --> question everything).

The following are less of a problem, as memory is usually reliable. However if you choose not to trust your RAM, you cannot trust these operations either:
* Retagging might prompt rewrite of full file to drive. Then it is read from drive, stored in RAM, written to drive. If you want to avoid this, use external metadata as I've pointed out earlier. Cons: you will get a foobar2000-only solution for your updated metadata. Of course, a corruption might corrupt those files, but your audio will be intact.

* Defragmentation will mean a file is read to RAM before written to a different place in the drive. The very same considerations as for rewrite by retagging apply: it is generally no problem, however you have made it one if you don't trust RAM.
Thanks for this. https://www.dbpoweramp.com/Help/perfecttunes/accuraterip.htm But it would presumably do me no good because while storage space is relatively cheap-and I could later delete the songs I didn’t want to rip in the first place-I’ve yet been inclined to take the time to rip an entire CD album, and that’s the only way it could check for errors.

And is this also true of AccurateRip? If yes, no wonder users have optical drives dying on them so often. And I’ve yet to find optical drives, optimized for CD reading and with ultra reliable laser assembly and transport design for longevity (e.g. audiophile CD transports?). Widely upgraded production practices for mass issued music CDs with the goal of delivering discs with less errors than ever before is certainly sheer fantasy. 

Perhaps, therefore, no other means but Accuraterip could be conceived for detecting read/ripping errors with reasonable accuracy, though requiring the whole disc to be ripped.

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #16 –
Quote from: nmxny24 on
Thanks. Maybe something like this https://www.qnap.com/en/product/ts-451%2B as long as fan noise levels aren’t objectionably highly before I’d get around to installing it in another room and routing data between it and my pc.

I didn’t finishing viewing the voluminous specs and features of those Qnap models, but how does Qnap error prevention and/or alerting during backups compare with that of ZFS or Btrfs, which are evidently the SOTA in error minimizing redundant backup systems?
Noise level is included in the specs and for that model it's 16.9 db(A) which is absolutely OK.

I'm suggesting ZFS or Btrfs on your workstation and backups to a SOHO NAS (RAID 1, 5, 6, 5+spare and S.M.A.R.T. monitoring), you're supposed to work on the former and never on the latter, if you're fearful in regards to the backup process I use Rsync but CIFS/SMB, FTP and RTRR are also provided.

Everything can fail, it doesn't mean it will, the probability of something bad happening to files on a local ZFS/Btrfs volume and at the same time to the relative backup on a RAID volume in a NAS is very slim.
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #17 –
Quote from: nmxny24 on
Perhaps, therefore, no other means but Accuraterip could be conceived for detecting read/ripping errors with reasonable accuracy, though requiring the whole disc to be ripped.
It takes minutes to rip a CD, once it's done fine by AccurateRip just calculate the checksum of only the files you want to keep (MD5, SHA256 or whatever you like), back them up and get rid of the rest.
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #18 –
Quote from: nmxny24 on
while storage space is relatively cheap-and I could later delete the songs I didn’t want to rip in the first place-I’ve yet been inclined to take the time to rip an entire CD album, and that’s the only way it could check for errors.
Well then, doing all that work for less than a CD ... but if that is your mode, feel free.

People ripping only tracks is actually the reason why AccurateRip works on single tracks and not full CD images. If you use dBpoweramp as a ripper, it will rip single tracks and - provided you give the right settings, at least - populate an <ACCURATERIPDISCID> tag which PerfectTunes will use to recognize a track-based rip.

Caveat: I've used the paid version of dBpoweramp, and off the top of my head I don't remember precisely which features are currently in the free version.

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #19 –
Quote from: DARcode on
Noise level is included in the specs and for that model it's 16.9 db(A) which is absolutely OK.

I'm suggesting ZFS or Btrfs on your workstation and backups to a SOHO NAS (RAID 1, 5, 6, 5+spare and S.M.A.R.T. monitoring), you're supposed to work on the former and never on the latter, if you're fearful in regards to the backup process I use Rsync but CIFS/SMB, FTP and RTRR are also provided.

Everything can fail, it doesn't mean it will, the probability of something bad happening to files on a local ZFS/Btrfs volume and at the same time to the relative backup on a RAID volume in a NAS is very slim.
Sorry for huge delay; the pitfalls of life. So, from https://www.qnap.com/en-us/product/ts-h686 , I thought of could instead back up to this one with larger storage capacity. https://www.qnap.com/en-us/product/ts-664

Trouble is it's been well over a year since I've reviewed RAID configurations; the only one I ever used was a pair of mirrored drives in ancient Dell pc, and that was pre-built. I was later successful in using a Promise Technology RAID card to mirror a pair of storage HDDs in the same pc. But this time I will have to get https://www.ericscomputerworld.com/about-us.html or https://www.microcenter.com/search/search_results.aspx?N=&cat=&Ntt=qnap&searchButton=search to configure the drives for me.

What RAID configuration do you recommend for the h-686 NAS and for the TS-664 NAS?

 
 

Re: Bit Error Correction for CD Track Ripping/Saving & File Backups?

Reply #20 –
Quote from: nmxny24 on

Could you please recommend which data integrity and bit correcting programs are currently the best and easiest to use for non-coders and other dummies?


I already said in your previous post but you probably oversighted it.
So, in short:
easiest way to setup are Reed-Solomon code based software /parity error correction programs which are simple to use and you don't need expensive equipment.

Multipar
https://github.com/Yutaka-Sawada/MultiPar

and ICE-ECC v2.7 are free to use.

Also WinRAR support error corection.
You can check and repair damaged archive/ files up to given percentage which you determine at file creation.

I've tested extensively ICE-ECC and WinRAR and they work flawlessly.
lame --abr 288 -f --lowpass 17 (+ mp3gain@92 dB)