ripping CD via music sever or computer

[monteverdi]

I was ripping some of my CDs on my old macbook using XLD. I found that task quite boring and since the optical drive in my old laptop died and my new MacBook Pro doesn't have one I have not done any ripping recently. Presently I am mostly downloading or streaming and listening to my CDs via my CD transport which sounds better than any ripping I did. I like the simple physical act of getting up and searching for a CD instead of being on my computer but ripping has the advantage that one can use these files on different devices like my DAP (AK120) or my SD-trans 384(restricted to WAV) or a future second audio system.

Talking to some audio dealers they claim that the quality of the rips are much better using dedicated music servers. I do not understand that statement as any rip which is accurate should be identical to other accurate rips. But I would prefer not to use my MacBook for audio purposes so I am interested in some of the newer music severs which have builtin optical drives and can +/- automatically rip CDs like Naim Unity Core or Innuos Zen (mini /-ith). One main concern is whether these rips are useable universally by other devices  (of course the file format itself should be one these these devices can use. That includes the metadata! 

So is ripping with these servers really more convenient and are the files fully transferable? And which one?

[BilboAlaska]

I just got a Bluesound Vault 2 and started entering cds. So simple. You don't need a computer on, just as long as the Vault is plugged into the Web.  Nothing could be more simple. I liked it so much that I got a Node 2 for another system in another room and they both playback from the same app on a computer, iPad, iPhone. Once you start the playing you can shut off the iPad. 

Also they play Tidal streaming service beautifully. Or whatever you want.

Love them!

[audiventory]

3 hours ago, monteverdi said:

Presently I am mostly downloading or streaming and listening to my CDs via my CD transport which sounds better than any ripping I did.

 

Probably, your CD transport have better DAC, than hardware, that playback ripped files.

 

It is not ripping matter.

 

Any tools that read CD's digital content (CD transports, drives and rippers) are differed (for digital part) in detecting and restoring (if the tool can) error ability.

 

These errors are coarse by sound (interruptings, clicks, etc.), as rule.

[monteverdi]

8 hours ago, audiventory said:

 

Probably, your CD transport have better DAC, than hardware, that playback ripped files.

 

It is not ripping matter.

 

Any tools that read CD's digital content (CD transports, drives and rippers) are differed (for digital part) in detecting and restoring (if the tool can) error ability.

 

These errors are coarse by sound (interruptings, clicks, etc.), as rule.

No every source uses the same DAC (Devialet 250 Pro) and my CD transport(Pro-Ject RS) is only a transport (without any DAC). One relevant difference is which input is used: AES/EBU for the  CD transport, SPDIF for the CD-trans and USB for the MacBook. I used ethernet with the AIR application before but that does not work anymore with that funny USB-C only connection in my new Macbook Pro.

[davide256]

All CD's are basically a digital file. Ripping allows you to store the music in a purely digital playback solution vs spending

an ungodly amount of money on  a real time mechanical transport solution that won't add jitter and intermittent error during playback.

Ripping apps like DBpoweramp have checksum data for most CD's so that you can validate your music ripped had no file errors.

Real time performance is important too in a digital playback solution but the opportunity for playback error is much lower.

[audiventory]

32 minutes ago, davide256 said:

Ripping apps like DBpoweramp have checksum data for most CD's so that you can validate your music ripped had no file errors.

 

1. Do you suppose the checksum(s) is correct with 100% probability?

Even in case if all checksums in the database for same CD are identical? Where there is 100% guarantee that all these sums are correct?

Only master-record holder have WAV file, that may be used for calculating the correct checksum.

 

2. Do you sure that each ripper calculate the checksum same way?

 

3. Modern CD drives have enough powerful own abilities for error detecting. Multiple reading with eliminating of buffering and statistical processing allow not only detect errors, but attempt to restore audio data (without guarantee, of course). Read more http://samplerateconverter.com/content/safe-audio-cd-ripping-technology

[foodfiend]

13 hours ago, monteverdi said:

I was ripping some of my CDs on my old macbook using XLD. I found that task quite boring and since the optical drive in my old laptop died and my new MacBook Pro doesn't have one I have not done any ripping recently. Presently I am mostly downloading or streaming and listening to my CDs via my CD transport which sounds better than any ripping I did. I like the simple physical act of getting up and searching for a CD instead of being on my computer but ripping has the advantage that one can use these files on different devices like my DAP (AK120) or my SD-trans 384(restricted to WAV) or a future second audio system.

Talking to some audio dealers they claim that the quality of the rips are much better using dedicated music servers. I do not understand that statement as any rip which is accurate should be identical to other accurate rips. But I would prefer not to use my MacBook for audio purposes so I am interested in some of the newer music severs which have builtin optical drives and can +/- automatically rip CDs like Naim Unity Core or Innuos Zen (mini /-ith). One main concern is whether these rips are useable universally by other devices  (of course the file format itself should be one these these devices can use. That includes the metadata! 

So is ripping with these servers really more convenient and are the files fully transferable? And which one?

You did not mention what you used to play your ripped CDs. Frankly, if you were using the old MacBook, I would have told you that it is not ideal. I can't remember the exact reason, but music playback on a MacMini beats that of a MacBook, for example.

 

You mention that you enjoy the physical act of getting up and searching for a CD. In that case, why rip your files, or use the likes if the Naim Unity Core? Would not running a music server remove the need of that physical act of getting up and searching for a CD (similar to that of playing vinyl)? In that case, would that not take away one of the things you like of music replay?

 

Talking about ripping, the likes of XLD does check the rip versus other rips of the same title, as well as the number of errors and retries the drive makes. This is similar to EAC on the PC platform. Servers like the Unity Core cater to the "lazy audiophile" who cannot be bothered with the hassle of ripping. I am not too sure how these cater to errors on the CD and ripping process, and if they do check the accuracy of the rip versus the databases that EAC and XLD use. For me, I rather do the ripping manually, since I can check the accuracy of each rip, and decide if I should re-rip a disc. That said, I have ripped all of my CDs (more than 3000 titles), and so any new rips are for new purchases, which happen only a few at a time (and not 100s).

 

[audiventory]

1 hour ago, monteverdi said:

No every source uses the same DAC (Devialet 250 Pro) and my CD transport(Pro-Ject RS) is only a transport (without any DAC).

 

Need check audio player software settings and abilities.

[pkane2001]

I'm in the process of ripping over 1,500 CDs I've accumulated over the years to a NAS. The process is slow, but rewarding. I have multiple playback systems in my house, and the rips are accessible from any of them over Wi-Fi. I didn't start on the process until I found a configuration that produced the same or better sound than my dedicated CD transport with I2S output. 

 

For my main system, I'm using HQPlayer on a Macbook Pro feeding ES 9028pro DAC upscaled to DSD256. The CD transport has been turned off for many weeks now, and may go up for sale soon  

 

I'm ripping using XLD and dbPowerAmp (works better than XLD for a number HDCD disks I have, but both are certainly up to the task). I bought a $25 external CD drive for this task, and it's been working great so far but I still have a long way to go.

[monteverdi]

2 hours ago, foodfiend said:

You did not mention what you used to play your ripped CDs. Frankly, if you were using the old MacBook, I would have told you that it is not ideal. I can't remember the exact reason, but music playback on a MacMini beats that of a MacBook, for example.

 

You mention that you enjoy the physical act of getting up and searching for a CD. In that case, why rip your files, or use the likes if the Naim Unity Core? Would not running a music server remove the need of that physical act of getting up and searching for a CD (similar to that of playing vinyl)? In that case, would that not take away one of the things you like of music replay?

 

Talking about ripping, the likes of XLD does check the rip versus other rips of the same title, as well as the number of errors and retries the drive makes. This is similar to EAC on the PC platform. Servers like the Unity Core cater to the "lazy audiophile" who cannot be bothered with the hassle of ripping. I am not too sure how these cater to errors on the CD and ripping process, and if they do check the accuracy of the rip versus the databases that EAC and XLD use. For me, I rather do the ripping manually, since I can check the accuracy of each rip, and decide if I should re-rip a disc. That said, I have ripped all of my CDs (more than 3000 titles), and so any new rips are for new purchases, which happen only a few at a time (and not 100s).

 

I played my files from my MacBook via Audirvana + and USB (without any usb filter/reclocker) or Devialet AIR using an ethernet connection (not possible with the new MacBook). Later was better. I also copied WAV files to SD-cards and played them through my SD-trans 384 which is by far the best sounding playback option! So it is not necessarily the rips! But that system is basically lacking any real UI and therefore not something for playback of large music collections.

When using XLD I made sure that the rips were correct (except some rare disks which were not in any database). I do not want to use my present  MacBook for audio and therefore I was thinking of music servers with ripping ability. What is important for me to make the rips portable like a DAP or a system in a different location so a WLAN/LAN is convenient but would not work for that! That also means frequent file copying.

One option I am interested in is an Intel NUC running ROCK and Roon but I do not know wether I can integrate a ripping software without the need for a second OS.

[foodfiend]

11 hours ago, monteverdi said:

I played my files from my MacBook via Audirvana + and USB (without any usb filter/reclocker) or Devialet AIR using an ethernet connection (not possible with the new MacBook). Later was better. I also copied WAV files to SD-cards and played them through my SD-trans 384 which is by far the best sounding playback option! So it is not necessarily the rips! But that system is basically lacking any real UI and therefore not something for playback of large music collections.

When using XLD I made sure that the rips were correct (except some rare disks which were not in any database). I do not want to use my present  MacBook for audio and therefore I was thinking of music servers with ripping ability. What is important for me to make the rips portable like a DAP or a system in a different location so a WLAN/LAN is convenient but would not work for that! That also means frequent file copying.

One option I am interested in is an Intel NUC running ROCK and Roon but I do not know wether I can integrate a ripping software without the need for a second OS.

Your digital music playback had lots of issues (MacBook playback limited by hardware, SD-trans 384 playback limited by UI).

 

One thing that is clear is that you are looking for a convenient solution to rip your music, as well as to host/serve it. Am I right?

 

You have not stated what DAP you use (impacts on file format), and how you intend to get your music on to your DAP (are you going to use your new MacBook?), how you would play the music on your second audio system (streaming?).

 

Do realize that the size of your music collection can sometimes preclude some solutions, due to their lack of expansion options. The products that your HiFi retailer has mentioned are "neat solutions", but it does impact on flexibility, and also raises the cost of implementation and complexity of migration out of that solution. Also consider your back-up solutions at this stage, as it may impact your decision (you may end up with a NAS).

[monteverdi]

15 hours ago, foodfiend said:

Your digital music playback had lots of issues (MacBook playback limited by hardware, SD-trans 384 playback limited by UI).

 

One thing that is clear is that you are looking for a convenient solution to rip your music, as well as to host/serve it. Am I right?

 

You have not stated what DAP you use (impacts on file format), and how you intend to get your music on to your DAP (are you going to use your new MacBook?), how you would play the music on your second audio system (streaming?).

 

Do realize that the size of your music collection can sometimes preclude some solutions, due to their lack of expansion options. The products that your HiFi retailer has mentioned are "neat solutions", but it does impact on flexibility, and also raises the cost of implementation and complexity of migration out of that solution. Also consider your back-up solutions at this stage, as it may impact your decision (you may end up with a NAS).

Yes I am trying to find a convenient and accurate way of ripping and it would great that this device is also a server for all my music including downloads and steaming. In order to migrate these files to other devices (my DAP is Astell&Kern AK120 so most file types will work) requires likely a backup on a USB drive or NAS and then connecting that drive to my computer and copying it on other drives or SDcards. Not something I am looking forward to.

 

[audiventory]

2 hours ago, monteverdi said:

Yes I am trying to find a convenient and accurate way of ripping and it would great that this device is also a server for all my music including downloads and steaming.

 

"More accuracy" is "lower number of errors". I still don't found proper comparison of rippers by accuracy.

Personal impressions by sound and comparing with checksum database is not technically correct way.

 

For such comparison need test-damaged CD with exactly known binary audio content. Here my comparison methodic http://samplerateconverter.com/content/what-best-cd-ripper-software-how-compare-audio-cd-rippers

 

[monteverdi]

1 hour ago, audiventory said:

 

"More accuracy" is "lower number of errors". I still don't found proper comparison of rippers by accuracy.

Personal impressions by sound and comparing with checksum database is not technically correct way.

 

For such comparison need test-damaged CD with exactly known binary audio content. Here my comparison methodic http://samplerateconverter.com/content/what-best-cd-ripper-software-how-compare-audio-cd-rippers

 

As far as I understand the problem of bit accuracy it is presently somewhat underestimated compared to time accuracy (jitter). But how one knows if the CD is bit correct or if there is an difference between different releases and pressings? So If one looks at bit differences of different rips (in the data bases including checksum) are they caused by the ripping process or that they are caused by difference in CDs. At least I have the experience that CDs (not scratched one) sometimes can sound different even they are from the same mastering.

Thinking about it more how accurate are then downloads- at least they should not be derived from CD rips.

[audiventory]

2 hours ago, monteverdi said:

As far as I understand the problem of bit accuracy it is presently somewhat underestimated compared to time accuracy (jitter). But how one knows if the CD is bit correct or if there is an difference between different releases and pressings? So If one looks at bit differences of different rips (in the data bases including checksum) are they caused by the ripping process or that they are caused by difference in CDs. At least I have the experience that CDs (not scratched one) sometimes can sound different even they are from the same mastering.

Thinking about it more how accurate are then downloads- at least they should not be derived from CD rips.

For CD ripping jitter can cause binary errors (wrong checksum).

 

> But how one knows if the CD is bit correct or if there is an difference between different releases and pressings?

 

It is impossible without original WAV, that used for forming pressing matrix. Unfortunately, I’m not expert in CD manufacturing and don’t know details of process.
Probably, there may be reasons, that cause wrong pressing result.

But comparing of ripping result with the above mentioned original WAV give us 100% probability of correct error detection.
If WAV is not damaged, of course. But I don’t consider such case.

> So If one looks at bit differences of different rips (in the data bases including checksum) are they caused by the ripping process or that they are caused by difference in CDs.

 

One ripper may cause different errors for different ripping seances even.

Different ripper software, that have access to raw stream data and error flags, uses same programming interface.
I suppose, «hardware ripper» like music server have same access abilities.
But CD-drive hardware have more abilities, because it control laser and output-reading-element voltage.

Ripped raw-audio-data errors depend on how and how many times data are read.

After it we can apply statistical processing for these several readings with considering of error flags. There may be different algorithms, that impact to final result (denied and probably restored bytes - if a ripper can recover errors).

CD-audio player may apply interpolation of damaged data after final error detection.

 

 > At least I have the experience that CDs (not scratched one) sometimes can sound different even they are from the same mastering.

 

It is complex matter. If there no binary difference and used same hardware, there should not be sound difference.

 

We have scheme:

CD > buffer > processing hardware/software > buffer in software/hardware > line (SPDIF/USB/etc.) > asynchronous buffer of DAC > DAC chip

 

Jitter is matter for reading of the asynchronous buffer of DAC by internal clock of the DAC.

Identical CDs may have different binary errors, if quality of recording/reading of the CDs at edge of reading (different for different hardware/software) stability.

As example, we can write 1 WAV on 2 CD-Rs by different manufacturers or parties. And we can get different binary raw audio data during playback.

[foodfiend]

8 hours ago, monteverdi said:

Yes I am trying to find a convenient and accurate way of ripping and it would great that this device is also a server for all my music including downloads and steaming. In order to migrate these files to other devices (my DAP is Astell&Kern AK120 so most file types will work) requires likely a backup on a USB drive or NAS and then connecting that drive to my computer and copying it on other drives or SDcards. Not something I am looking forward to.

 

Try to look at your workflow and see what works best. A separate computer used to rip and manage your music (transfer to your DAP), and a NAS to serve the music may be an alternative (there are NASes that can run as the Roon Core, for example). Ultimately, User Experience is rather subjective and personal, so I wish you all the best in your search for audio nirvana!

[Dan Gravell]

Not all music servers are created equal on this.

 

You mentioned metadata:

On 25/04/2017 at 6:32 AM, monteverdi said:

That includes the metadata!

 

... And that's a good example.

 

For WAV rips, for example, some music servers (the old Naim ones included, not sure about the new ones) won't embed metadata into the files themselves, preferring their own proprietary data format which is of no use to other music players. I think it's important the source files are as transferrable as possible.

 

Next, in the case of clashes you need to be able to resolve what the correct metadata is. In fact, there are numerous occasions where you need some level of control, so does the server's app allow you to edit this?

 

So I think you have to do some research.

[foodfiend]

1 hour ago, Dan Gravell said:

Not all music servers are created equal on this.

 

For WAV rips, for example, some music servers (the old Naim ones included, not sure about the new ones) won't embed metadata into the files themselves, preferring their own proprietary data format which is of no use to other music players. I think it's important the source files are as transferrable as possible.

 

So I think you have to do some research.

Totally agree about that statement. I remember that the old Olive systems used to lock everything up. I do not have personal experience with the Naim systems, but I do understand that you can elect to save files as FLAC or WAV. The WAV container does not normally have a way of saving metadata, but I am not sure if they do attach metadata to the FLAC files (since FLAC can store metadata). Can someone confirm? Or does Naim still use their proprietary data format even for FLAC? This has always been the root of my reluctance to move into systems like that, due to the difficulty of migrating from the platform in the future.

 

Also, some of these servers use a version of the LINUX OS, which can make OS file systems a bit problematic. You may not be able to share an external HDD between your computer (Mac or PC) and server, but only link them through a client-server protocol. It might be okay for some, but when you are transferring TBs of music, Ethernet or Wifi is still painfully slow.

 

While most servers claim to play most of the music formats, do also understand that there is normally a preferred format (for whatever reason), where new ripped music is stored in (compared with legacy music). This would give you an idea of how truly open the system is to different formats and how easy to make a future migration.

[pkane2001]

13 hours ago, audiventory said:

 

"More accuracy" is "lower number of errors". I still don't found proper comparison of rippers by accuracy.

Personal impressions by sound and comparing with checksum database is not technically correct way.

 

For such comparison need test-damaged CD with exactly known binary audio content. Here my comparison methodic http://samplerateconverter.com/content/what-best-cd-ripper-software-how-compare-audio-cd-rippers

 

Yuri, as an end-user ripping a set of CDs, I'm much less concerned with the 'technically correct' way to compare software. All I care about is that CDs are being imported correctly into my NAS and comparing a checksum against an on-line database is a perfectly valid way to do so.

 

I'm now about half-way through importing my collection, and so far, I've run into about 3 tracks that didn't match the on-line databases. I've retried them with different settings and multiple ripping software, and still there was a mismatch, so either the CD is damaged or the online databases don't match my CD issue. Whatever the case, I just accepted those few tracks as different out of over 700+ albums that I've imported so far.

[davide256]

11 minutes ago, pkane2001 said:

Yuri, as an end-user ripping a set of CDs, I'm much less concerned with the 'technically correct' way to compare software. All I care about is that CDs are being imported correctly into my NAS and comparing a checksum against an on-line database is a perfectly valid way to do so.

 

I'm now about half-way through importing my collection, and so far, I've run into about 3 tracks that didn't match the on-line databases. I've retried them with different settings and multiple ripping software, and still there was a mismatch, so either the CD is damaged or the online databases don't match my CD issue. Whatever the case, I just accepted those few tracks as different out of over 700+ albums that I've imported so far.

Its not uncommon for a disc to be re-released and for the new release to have a track or 2 that's been altered for some reason... as I recall those usually show up as a "minority report" number of verified CRC's for the track vs the more common release count of verified CRC's. Pop artists with  mega hits are the usual culprit. What I hate is when the lookup tells you that you would have gotten more tracks on another release...

[audiventory]

1 hour ago, pkane2001 said:

I've retried them with different settings and multiple ripping software, and still there was a mismatch, so either the CD is damaged or the online databases don't match my CD issue.

 

It's that I said: no sense use external database, because we have low probability, that ripper, using C2+re-reading+buffer-eliminating, miss error.

The database is excess element of ripping system. Any system should be as simpler as possibly. Without additional elements that increase degree of uncertainty.

[audiventory]

1 hour ago, davide256 said:

ts not uncommon for a disc to be re-released and for the new release to have a track or 2 that's been altered for some reason... as I recall those usually show up as a "minority report" number of verified CRC's for the track vs the more common release count of verified CRC's.

 

Thank you for interesting information.

[Dan Gravell]

On 27/04/2017 at 1:18 PM, foodfiend said:

The WAV container does not normally have a way of saving metadata, but I am not sure if they do attach metadata to the FLAC files (since FLAC can store metadata). Can someone confirm? Or does Naim still use their proprietary data format even for FLAC? This has always been the root of my reluctance to move into systems like that, due to the difficulty of migrating from the platform in the future.

 

WAV has always had a way of saving metadata, it's a proper container format with provision for metadata.

 

Naim certainly embeds the tags into FLACs.

[foodfiend]

59 minutes ago, Dan Gravell said:

 

WAV has always had a way of saving metadata, it's a proper container format with provision for metadata.

 

Naim certainly embeds the tags into FLACs.

My bad, just that most WAV files don't include the metadata, and it is not well-handled by many music replay programs.

[Dan Gravell]

Yeah, you're right there, although support is improving... https://www.blisshq.com/music-library-management-blog/2016/02/16/music-players-support-wav-tags/