3000 CD's To Rip - Why Not Just Record Them All To DSD With This Instead?

[Paul R]

+1. 100% agree with this

 

As TedB used to say "if it's PCM let me hear PCM" "If it's original DSD then let me here DSD."

 

Then sort all the tack formats with something like Audirvana and feed the DSD tracks to a DSD capable DAC and the PCM tracks to a DAC that handles PCM well..> that's why I have still held onto my old Benchmark DAC1.. Cheers.

 

Whereas I say - convert to DSD for playback and enjoy stuff that sounds like it is on a $10K turntable with a very expensive cartridge....

[Skeptic]

Whereas I say - convert to DSD for playback and enjoy stuff that sounds like it is on a $10K turntable with a very expensive cartridge....

We get it Paul, your DAC sounds better with DSD. You don't have to keep pushing it on everyone all the time.

[kumakuma]

We get it Paul, your DAC sounds better with DSD. You don't have to keep pushing it on everyone all the time.

 

In a grumpy mood today, Skep?

[bogi]

Perhaps upsampling to 2x DSD sounds amazing on your current system, but in five years you change one component and now DSD might sound worse than the original 16-bit/44.1kHz PCM. Do you think that you will want to go through the process of ripping 3000 discs again five years from now? And it's possible that you will be unable to rip some of your older discs accurately by then. In the last few years, I have noticed that a number of discs in my collection have now become unreadable due to disc rot

 

I fully agree with this.

 

One point I did't find in the previous discussion is quality of PCM to DSD conversion. More tools exist for that and they provide different results. Here is one comparison of offline tools: Archimago's Musings: ANALYSIS: A Comparison of DSD Encoders & Decoders (KORG AudioGate, JRiver MC, Weiss Saracon)

Comparison of HQPlayer, Foobar and JRiver 'on the fly' implementation of PCM to DSD conversion is available here http://www.computeraudiophile.com/f11-software/head-head-jrmc19-foobar-sacd-and-hq-player-doing-cd-standard-lpcm-sampled-16-bits-and-44-100-times-second-aimed-reproducing-sound-20-20-000hz-direct-stream-digital-and-native-direct-stream-digital-20687/ I tested different sigma-delta modulators, provided by HQPlayer and I found audible differences here too. So the sigma-delta modulation algorithms, required for PCM to DSD conversion, affect sound and their implementation is important.

 

Therefore it is clearly better to losslessly retain the CDs in their native PCM 44.1k/16bit format. You can convert them anytime to a format you like. If you want to listen them through DSD capable DAC, you can use on the fly PCM to DSD conversion. It is available in HQPlayer, Foobar, JRiver and through foo_dsd_asio proxy it may function in other ASIO capable players too.

 

Regarding FLAC or ALAC ... I never used ALAC and I don't miss it. And maybe someone never used FLAC. Not so important. Both are lossless and both support metadata.

[Paul R]

We get it Paul, your DAC sounds better with DSD. You don't have to keep pushing it on everyone all the time.

 

Don't like having your pronouncements from on high challenged this morning?

 

No, DSD just sounds better most of the time, and on many systems, not just on a particular DAC. Often it sounds spectacularly better than PCM. Many, though I grant you not all, people find transcoding Redbook PCM to DSD128 sounds far better than PCM Dacs which upsample (courtesy of various filters and algorithms) to PCM to 384k anyway.

[Bill Lord]

There are some really good posts in this thread. In my attempt to add to this discussion, use two 400 Disc CD Changers over the course 18 months swap between the two every two weeks. Have fun splitting and adding metadata. That's a lot of work. my opinion spend 6 months ripping them.

 

On a more technical note: I rip to binary files (.bin).That's straight 1's & 0's. When I use that file to burn a disc, it's 1-1 copy and its recognized as the original from all the CDDB look up tools. The non free software I uses for the Mac is called Toast Titanium 11. There are others out there.

 

XLD (MAC) & EAC(WIN) are able to transcode raw PCM .bin files to FLAC/ALAC/AIFF. Then following the Computer Audiophile ripping methodology, I have the raw PCM/bin/cue file, FLAC file (With Metadata from CDDB/Musicbrainz and fixes from BLISS), 320 AAC on my iPod Classic, ALAC file in iTunes for playing at home. I also play the ALAC files as local files inside Spotify's iOS App.

[Skeptic]

Your understanding is not correct, as ALAC is CRC checked.

Testing shows that this is not the case: Which is the best lossless codec? - Hydrogenaudio Forums

Lossless comparison - Hydrogenaudio Knowledgebase

 

Unless you have specific requirements which do not permit its use, you should be storing your music in the FLAC format.

[Bill Lord]

Testing shows that this is not the case: Which is the best lossless codec? - Hydrogenaudio Forums

Lossless comparison - Hydrogenaudio Knowledgebase

 

Unless you have specific requirements which do not permit its use, you should be storing your music in the FLAC format.

 

Very cool, I did not know this feature & thanks for the reference. You direct us to FLAC because of CRC feature? From the ref article I saw differences but not enough to go one way or the other besides my aforementioned comment. Can you validate that CRC inside the codec is effective? I thought this was why we have RAID, no? Thanks.

[Paul R]

Testing shows that this is not the case: Which is the best lossless codec? - Hydrogenaudio Forums

Lossless comparison - Hydrogenaudio Knowledgebase

 

Unless you have specific requirements which do not permit its use, you should be storing your music in the FLAC format.

 

Gads - those guys really hate Apple don't they? If you change so much as a single byte in a ALAC file (or an AIFF file for that matter) none of the decent players will play the file in the first place. Try it. This file has a single byte changed in it from the original.

 

Your *only* defense against file corruption is good backups. ALAC is every bit as good as FLAC for storing files in compressed format. Better actually, since Apple players usually do not support FLAC at all while all Windows and Linux players do support ALAC.

 

-Paul

[Skeptic]

Very cool, I did not know this feature & thanks for the reference. You direct us to FLAC because of CRC feature? From the ref article I saw differences but not enough to go one way or the other besides my aforementioned comment. Can you validate that CRC inside the codec is effective? I thought this was why we have RAID, no? Thanks.

RAID protects against drive failures. It does not protect against corrupted files.

If a file is corrupted, or accidentally modified/deleted, that change it will automatically be copied to every other drive in the RAID as well.

 

This is why RAID is not a backup solution. It's more about keeping servers online if a drive fails.

You need scheduled backups to external disks in addition to (or instead of) RAID to protect your data.

I would back up to a minimum of two separate drives, and rotate them. I took the paranoid route and have drives for daily/weekly/monthly/yearly backups in rotation, so that I can go back two years if I have to.

 

The CRC checking is used to determine whether or not a file is corrupt.

If it has been corrupted, the only solution is to restore it from a backup.

 

There are filesystems under development such at BTRFS which are capable of automatically detecting corruption and correcting it, but these are not currently in use on mainstream operating systems. (Windows/OS X)

 

Gads - those guys really hate Apple don't they? If you change so much as a single byte in a ALAC file (or an AIFF file for that matter) none of the decent players will play the file in the first place. Try it. This file has a single byte changed in it from the original.

[ATTACH=CONFIG]16612[/ATTACH]

 

Your *only* defense against file corruption is good backups. ALAC is every bit as good as FLAC for storing files in compressed format. Better actually, since Apple players usually do not support FLAC at all while all Windows and Linux players do support ALAC.

 

-Paul

Read the full post, and the ones linked within it. ALAC does no error checking.

Yes, if it is corrupted beyond a certain point or in a critical area it can no longer be read - as with any file - but it's not capable of doing things like detecting a single flipped bit as other codecs would.

 

To quote the post:

"In case of light corruption in non-critical parts however, files can be still be decoded and the affected parts are very short. With more corruption, iTunes simply refuses to play or convert the file."

 

Check the failure states for various other codecs as well, which is linked in that post:

FLAC

Replaced bytes: continues decoding when used the -F switch and reports error while decoding and at the end. Only sign of corruption was a hiccup.

Deleted bytes: continues decoding when used the -F switch and reports error while decoding and at the end. Only sign of corruption was a hiccup.

 

This is instead of the decoder crashing or refusing to play the file in many cases.

Sometimes, you won't have a backup to recover from - or that backup includes previously unreported corruption. The worst case scenario with FLAC is a lot better than most other codecs.

 

 

The point is that files stored as ALAC can be partially corrupted without any errors being reported by the decoder.

The only way to know is to fully play the file and actually notice that corruption, which will manifest as pops/clicks or short bursts of noise, and may be missed first time around. (you would be surprised at how easy it can be to miss if you aren't paying attention)

 

By the time you realize this, it's entirely possible that you have updated all of your backups with a copy of this corrupted file.

 

 

It doesn't mean that ALAC should be avoided at all costs, but if I'm keeping an archival copy of the CD rip I would want it stored as FLAC.

If I need to play it on an iOS device or want to play it as DSD, I would create a duplicate track converted to ALAC or DSD for those purposes, and if my software can play ALAC but not FLAC I would replace it with something better.

[bogi]

Paul, people in my part of Europe mostly aren't living in the iWorld. It's not about hating Apple. Not only young people here are rather buying cheaper Android phones than iPhone and that's about other Apple products too. Almost all companies here are using Windows on PCs and the MS Office suite here acts as a standard for interchanging documents. In my territory ALAC is something very minor, relevant only to owners of iPods and iPads. Popular portable players here are iBasso DX50, FiiO X3 and some cheaper ones, like Sansa Clip, so no need for ALAC.

[bogi]

Bill Lord, if some of SW you are using has files open for writing and your computer looses power for any reason (power failure or other accidental powering off without proper shutdown), your filesystem can become corrupt, no matter if you are using RAID or not. The issue which can happen is logical corruption of filesystem structure and content, not hardware failure. RAID prevents you from consequences of hardware failure.

 

Backups and RAID are not the same thing. As logical file corruption is real risk, from my point of view backups are more important for music library than RAID or disk mirroring.

[alfe]

Don't like having your pronouncements from on high challenged this morning?

 

No, DSD just sounds better most of the time, and on many systems, not just on a particular DAC. Often it sounds spectacularly better than PCM. Many, though I grant you not all, people find transcoding Redbook PCM to DSD128 sounds far better than PCM Dacs which upsample (courtesy of various filters and algorithms) to PCM to 384k anyway.

 

You are diving into the dark side, DSD über alles.

[Paul R]

RAID protects against drive failures. It does not protect against corrupted files.

If a file is corrupted, or accidentally modified/deleted, that change it will automatically be copied to every other drive in the RAID as well.

 

This is why RAID is not a backup solution. It's more about keeping servers online if a drive fails.

You need scheduled backups to external disks in addition to (or instead of) RAID to protect your data.

I would back up to a minimum of two separate drives, and rotate them. I took the paranoid route and have drives for daily/weekly/monthly/yearly backups in rotation, so that I can go back two years if I have to.

 

The CRC checking is used to determine whether or not a file is corrupt.

If it has been corrupted, the only solution is to restore it from a backup.

 

There are filesystems under development such at BTRFS which are capable of automatically detecting corruption and correcting it, but these are not currently in use on mainstream operating systems. (Windows/OS X)

 

Read the full post, and the ones linked within it. ALAC does no error checking.

Yes, if it is corrupted beyond a certain point or in a critical area it can no longer be read - as with any file - but it's not capable of doing things like detecting a single flipped bit as other codecs would.

 

To quote the post:

"In case of light corruption in non-critical parts however, files can be still be decoded and the affected parts are very short. With more corruption, iTunes simply refuses to play or convert the file."

 

Check the failure states for various other codecs as well, which is linked in that post:

FLAC

Replaced bytes: continues decoding when used the -F switch and reports error while decoding and at the end. Only sign of corruption was a hiccup.

Deleted bytes: continues decoding when used the -F switch and reports error while decoding and at the end. Only sign of corruption was a hiccup.

 

This is instead of the decoder crashing or refusing to play the file in many cases.

Sometimes, you won't have a backup to recover from - or that backup includes previously unreported corruption. The worst case scenario with FLAC is a lot better than most other codecs.

 

 

The point is that files stored as ALAC can be partially corrupted without any errors being reported by the decoder.

The only way to know is to fully play the file and actually notice that corruption, which will manifest as pops/clicks or short bursts of noise, and may be missed first time around. (you would be surprised at how easy it can be to miss if you aren't paying attention)

 

By the time you realize this, it's entirely possible that you have updated all of your backups with a copy of this corrupted file.

 

 

It doesn't mean that ALAC should be avoided at all costs, but if I'm keeping an archival copy of the CD rip I would want it stored as FLAC.

If I need to play it on an iOS device or want to play it as DSD, I would create a duplicate track converted to ALAC or DSD for those purposes, and if my software can play ALAC but not FLAC I would replace it with something better.

 

Well, we just have to disagree there. I find that even a single flipped bit changes a byte and an incorrect byte is detected. That reports the file as corrupt. YMMV.

 

I also have a bit more sophisticated backup system than the average audiophile, so I have about 30 versions of each file stored away. A changed file would be detected and reported in the periodic backup.

 

-Paul

[Paul R]

Paul, people in my part of Europe mostly aren't living in the iWorld. It's not about hating Apple. Not only young people here are rather buying cheaper Android phones than iPhone and that's about other Apple products too. Almost all companies here are using Windows on PCs and the MS Office suite here acts as a standard for interchanging documents. In my territory ALAC is something very minor, relevant only to owners of iPods and iPads. Popular portable players here are iBasso DX50, FiiO X3 and some cheaper ones, like Sansa Clip, so no need for ALAC.

 

That may be, but Microsoft Windows is agnostic between MacOS and Windows. A good move on Microsoft's part, since Word for example, was initially written for MacOS and ported to Windows.

 

But more importantly, your signature indicates you are using an iPod, which doesn't do FLAC, unless your modification enables it.

[goldsdad]

If you change so much as a single byte in a ALAC file (or an AIFF file for that matter) none of the decent players will play the file in the first place. Try it. This file has a single byte changed in it from the original.

[ATTACH=CONFIG]16612[/ATTACH]

 

 

Paul, I find it hard to believe an IT professional like yourself is really as naive as that post suggests. Surely, you actually know that the effect of changing a byte in an AIFF will depend on the location of that byte within the file's structure.

 

If you change a byte amongst the audio samples then the file will be played but you may hear a click or pop. Similarly, a changed byte in the artist name, for example, will not affect playback. And a changed byte in an optional chunk which the particular player ignores, say, packet stream data, won't affect playback.

 

However, yes, if you selectively change a critical byte in, say, the header, then the file will be rejected as unplayable.

[goldsdad]

RAID protects against drive failures. It does not protect against corrupted files.

If a file is corrupted, or accidentally modified/deleted, that change it will automatically be copied to every other drive in the RAID as well.

 

This is why RAID is not a backup solution. It's more about keeping servers online if a drive fails.

You need scheduled backups to external disks in addition to (or instead of) RAID to protect your data.

I would back up to a minimum of two separate drives, and rotate them. I took the paranoid route and have drives for daily/weekly/monthly/yearly backups in rotation, so that I can go back two years if I have to.

 

The CRC checking is used to determine whether or not a file is corrupt.

If it has been corrupted, the only solution is to restore it from a backup.

 

There are filesystems under development such at BTRFS which are capable of automatically detecting corruption and correcting it, but these are not currently in use on mainstream operating systems. (Windows/OS X)

 

Read the full post, and the ones linked within it. ALAC does no error checking.

Yes, if it is corrupted beyond a certain point or in a critical area it can no longer be read - as with any file - but it's not capable of doing things like detecting a single flipped bit as other codecs would.

 

To quote the post:

"In case of light corruption in non-critical parts however, files can be still be decoded and the affected parts are very short. With more corruption, iTunes simply refuses to play or convert the file."

 

Check the failure states for various other codecs as well, which is linked in that post:

FLAC

Replaced bytes: continues decoding when used the -F switch and reports error while decoding and at the end. Only sign of corruption was a hiccup.

Deleted bytes: continues decoding when used the -F switch and reports error while decoding and at the end. Only sign of corruption was a hiccup.

 

This is instead of the decoder crashing or refusing to play the file in many cases.

Sometimes, you won't have a backup to recover from - or that backup includes previously unreported corruption. The worst case scenario with FLAC is a lot better than most other codecs.

 

 

The point is that files stored as ALAC can be partially corrupted without any errors being reported by the decoder.

The only way to know is to fully play the file and actually notice that corruption, which will manifest as pops/clicks or short bursts of noise, and may be missed first time around. (you would be surprised at how easy it can be to miss if you aren't paying attention)

 

By the time you realize this, it's entirely possible that you have updated all of your backups with a copy of this corrupted file.

 

 

It doesn't mean that ALAC should be avoided at all costs, but if I'm keeping an archival copy of the CD rip I would want it stored as FLAC.

If I need to play it on an iOS device or want to play it as DSD, I would create a duplicate track converted to ALAC or DSD for those purposes, and if my software can play ALAC but not FLAC I would replace it with something better.

 

 

Excellent post to dispel some of the mis(dis?)information being presented from time to time.

[bogi]

But more importantly, your signature indicates you are using an iPod, which doesn't do FLAC, unless your modification enables it.

 

Rockbox is the answer ... it behaves as usual portable player with mass storage mode. Media files like FLACs can be copied directly to folder structure.

My iPod has dual boot, so I could boot also the original firmware, but I don't use it.

Rockbox - Free Music Player Firmware

 

But the main point of my modified iPod is hardware modification - bypassing the non-audiophile level analog stage behind the Wolfson DAC chip. Now I have pure line out, so portable headamp is needed. But the sound quality is much better.

[audiventory]

The prevailing opinion is that converting existing music to DSD is an improvement. Since I have 3000 cd's that I need to rip to a NAS I am about to purchase, wouldn't it make sense to buy this DSD recorder and just record and convert all of them to DSD for optimal quality?

 

Any analog conversion between digital formats only give useless losses.

 

Other hand convert CD to optimal (for DAC) format (non-oversampled sample rate / bit depth / DSD/PCM) possible some improve sound.

 

It possible do via inline ("on fly" with audio player) or preliminary offline (non-real time with audio converter). Both these ways give some losses.

 

But anyway better choice avoid any analog conversions. Except case of deliberate changing sound (thru tube circuits) for sound specificity. But it is we can consider as re-mastering, not as converting.

[Paul R]

Paul, I find it hard to believe an IT professional like yourself is really as naive as that post suggests. Surely, you actually know that the effect of changing a byte in an AIFF will depend on the location of that byte within the file's structure.

 

If you change a byte amongst the audio samples then the file will be played but you may hear a click or pop. Similarly, a changed byte in the artist name, for example, will not affect playback. And a changed byte in an optional chunk which the particular player ignores, say, packet stream data, won't affect playback.

 

However, yes, if you selectively change a critical byte in, say, the header, then the file will be rejected as unplayable.

 

Try it on an ALAC file. bet you a plugged nickel it fails if you change *any* byte in the file. I could be wrong though. In *any case* though - the only protection against a corrupt file is having multiple backups of the original uncorrupted file.

 

-Paul

[Bill Lord]

RAID protects against drive failures. It does not protect against corrupted files.

If a file is corrupted, or accidentally modified/deleted, that change it will automatically be copied to every other drive in the RAID as well.

..snip..

If I need to play it on an iOS device or want to play it as DSD, I would create a duplicate track converted to ALAC or DSD for those purposes, and if my software can play ALAC but not FLAC I would replace it with something better.

 

Bill Lord,

Backups and RAID are not the same thing. As logical file corruption is real risk, from my point of view backups are more important for music library than RAID or disk mirroring.

 

Thanks to the both of you, this changed my perspective.

Bill

[goldsdad]

Try it on an ALAC file. bet you a plugged nickel it fails if you change *any* byte in the file. I could be wrong though. In *any case* though - the only protection against a corrupt file is having multiple backups of the original uncorrupted file.

 

-Paul

 

You are wrong.

 

You should have tried it yourself before posting. I changed one byte about midway through an ALAC. The file played (as should be expected when you understand what's going on) with only a tiny burst of static about halfway through playback.

[audiventory]

I changed one byte about midway through an ALAC. The file played (as should be expected when you understand what's going on) with only a tiny burst of static about halfway through playback.

 

ALAC possible divided on frames like FLAC. I allow save track, and loss only 1 frame when it corrupted. Even if will corrupted several bytes into one frame.

 

Playback corrupted frame or not must decide player. If instead frame played zero level, possible some burst or click. Possible processing that remove click.

 

It like (and must sound) to corrupting audio stream passed thru digital (USB/SPDIF/HDMI) cabel.

[Condocondor]

So, I've not read this whole thread.  I didn't have time.  But, I've just downloaded JRiver 24 and tried an experiment:  I ripped a regular redbook CD "Raising Sand" by Allison Kraus and Robert Plant to both FLAC and DSD64 and played them side by side.  Now my DAC is an iFi Micro iDSD Black Label which handles DSD natively which might make a difference then if your DAC uses an AKM or SABRE  chip implementation. 

The results were very interesting.  The FLAC files seemed to be recorded at a higher volume than the DSD64 so I had to adjust volume upwards for comparison.  For me it was a no contest.  The CD ripped to DSD64 was noticeably smoother than FLAC file and more spacious sounding too.  I could listen with much less fatigue and greater enjoyment.  So....disc space be damned from here on out. 

I listen on my laptop exclusively with a DAC/AMP and higher end headphones.  I learned something really great here:  Rip CD's to DSD64 or higher if you want a smooth listen and want to get the most out of your redbook CD's.

[StephenJK]

On 1/19/2015 at 12:54 AM, TubeLover said:

The prevailing opinion is that converting existing music to DSD is an improvement. Since I have 3000 cd's that I need to rip to a NAS I am about to purchase, wouldn't it make sense to buy this DSD recorder and just record and convert all of them to DSD for optimal quality? And it's on sale too!

 

 

TASCAM DA-3000 | Sweetwater.com

 

And a review:

 

Everything Audio Network: Home Recording Review/BenchTest!TASCAM DA-3000 PCM/DSD Recorder:Perfect For Studio Pros And Audiophiles

 

 

JC

A number of years ago I had about 1,000 CD's that I wanted in digital format.  Storage was expensive at the time and I ended up doing them in 350kbps MP3 files, which as you know gives you about 1/4 the resolution of a CD.

 

It was a mistake.  I ended up having to rip them all over again to 14.4/16 bit FLAC files using the default of compression level 5.  

 

With any CD I don't think you can do any better than that.  Ripping or converting to DSD isn't going to add content that isn't there.  Plus, once in FLAC format you can always convert on the fly with something like JRiver without affecting the archival copy of your music.

 

Ripping CD's isn't a lot of work, it's just tedious.  Before you start, and again from painful experience, think about the folder and file structure you would like to use for the ripping process, regardless of the program you use. 

 

A lot of us use dBpoweramp, the gold standard in ripping CD's as it will go through a verification process using Secure Rip and Accurate Rip so you know that the digital copy is good to go and not have to verify it, to say nothing of looking up track titles and cover art from a number of Internet data sources.  Like many others, I found a computer with that software program was the fastest and most efficient way to go.  Most CDs take less than five minutes to fully process.

 

For file structure, I use Album Artist\Album Title\Track Number - Track Title

 

Some programs (such as dBpoweramp) will have a separate field for Artist and Album Artist.  That lets you use Bob Dylan for the Artist, and Dylan, Bob for the Album Artist.  That way your folders are sorted by absolute alphanumeric and your playback software can sort by either.

 

I see references to the use of a RAID etc. for data storage.  I just have a lot of copies in different places.  With over 1,000 CD's (at 14.4/16) ripped and about 1,500 recorded LPs (at 24/96) all that music will fit easily onto a 2 TB drive.  I have two copies at work with my backup drives, one at home for playback, one used for traveling and another my wife has for playback at her office.  

 

Good luck with your project!