Improving SQ of CD rips

[tuga]

It is . Just that others try to convince you that there is so much more out there to worry about . When the music sounds fine and you are just listening stop worrying and accept that what you have is very good and you do not need to look for problems that are not there .

The reason why a CD player user doesn't have to worry about these little detalis is because it's already been dealt with inside of the box.

I bought my first DAC in the early '90s when they became popular; until there was no talk of jitter.
Now people are using streamers and computers and home networks to play files, there are other issues, particularly with electrical noise, some which is dealt with inside hi-fi components and in the interfaces used to connect them, and even so there are sometimes gound loops and other humming issues...

 

[bencat]

But no two CD plays will be the same as each time you spin the disc it will error correct that play and that play only so none of the output from a CD is likely to be a bit perfect file . Once ripped and confirmed as bit perfect that file will stay that way . Nothing indicated in the quality of any of the streaming systems I have listened v to show any of the issues you suggest so I will stick to what I said and not invent additional things to worry about .

 

[Lawrence001]

Anyway, given big falls in the price of storage since someone took it upon themselves years ago to decide that a compression level of 5 was the optimal balance between file size and decompression processing, I've taken it upon myself to choose 0 as my optimal level for all my CD rips, and once I've finished my large collection I might go back and start again on the first batch of 2000 or so I did at 5.

 

[bencat]

That is lots of work Lawrence and good luck to you to complete it . Just because of this thread I ripped three versions of the same song at level 5 and level 8 and level 0 . Played each one in turn then stuck them on random honestly could not tell the difference between any of them . Will stick with 5 as I have a 2TB SSD HD for my music and it is getting very full . Rpi based distros do not easily recognise drives bigger than 2 TB so any extra space is useful .

 

[rdale]

Anyway, given big falls in the price of storage since someone took it upon themselves years ago to decide that a compression level of 5 was the optimal balance between file size and decompression processing, I've taken it upon myself to choose 0 as my optimal level for all my CD rips, and once I've finished my large collection I might go back and start again on the first batch of 2000 or so I did at 5.

Because FLAC is lossless you shouldn’t need to re-rip if you want to change the compression level.

 

[Lawrence001]

Because FLAC is lossless you shouldn’t need to re-rip if you want to change the compression level.

Interesting is there a batch process in Linux/Rpi that will take all my albums and uncompress them or reduce it to level 0? I'm also unsure if they've been volume adjusted (and I'm not talking about tags here) which was the other reason I wanted to do it.

 

[rdale]

Interesting is there a batch process in Linux/Rpi that will take all my albums and uncompress them or reduce it to level 0? I'm also unsure if they've been volume adjusted (and I'm not talking about tags here) which was the other reason I wanted to do it.

There is a command line program called ‘flac’ which sounds as though it would do it. I haven’t personally tried it because I use macOS for ripping. You certainly need to find out if your ripping software has been adjusting the volume by changing the PCM data as that is such a bad idea.

 

[Paul55]

For every file in your library you need to execute something like

flac -0 some_track.flac --force

which will recompress at compression level 0 preserving the metadata etc.

If replay gain metadata is present it will be preserved, which is fine as it is up to the replayer whether or not to act on it.

So, if your library were stored in the directory /media you might try,

find /media -name *flac -exec flac -0 {} --force \;

(and you would definitely make a copy of a part of your library to try it on first...)

The command 'find's every file in under the given directory, filters by 'name', so you only get flac extensions, the exec(utes) the flac command given, replacing the {} with the file name. The trailing \; mark the end of the command. This processes one file at a time, so should minimise the chances of unrecoverable catastrophe.

It will take some time.

Personally I'd leave it on 5, or even up it to 8. On the basis that I have the CPU cycles at compression time, and smaller cleaner data is preferable. There is no reasonable justification for lower levels of 'compression' sounding better.

 

[Lawrence001]

Personally I'd leave it on 5, or even up it to 8. On the basis that I have the CPU cycles at compression time, and smaller cleaner data is preferable. There is no reasonable justification for lower levels of 'compression' sounding better.

Thanks, could you explain the above comment a bit more please as I don't understand it?

 

[rdale]

Thanks, could you explain the above comment a bit more please as I don't understand it?

It means that the lower levels of compression for FLAC files only save computer CPU usage when ripping and compressing files. At playback time, the CPU usage to uncompress level 5 isn’t much greater than for level 0. So you’re essentially just spending more CPU at ripping time to save a small amount of disk space, but it will make little difference to the playback.

 

[Paul55]

When I was regularly ripping with dbPoweramp the FLAC encoding was happening during the rip and used all the CPU cores. In general the rip process determined how long the process took, since most of the encoding had been completed before the last track was ripped. This argument fails with very long tracks, but that's relatively uncommon in my collection. So running at 8 made the CPU warmer but didn't take noticeably much more of my time. With a modern CPU this would be even more the case.

If you're ripping on a Raspberry Pi or antique machine, or using a separate rip/encode process, then your experience would be different.

And it remains that there is no plausible mechanism for the compression option of FLAC to affect replay quality. The user should do what they feel works best.

 

[tuga]

I see no reason to compress FLAC unless you wish to carry the files in a phone or portable player and storage size is an issue.
As far as I know, for Windows users FLAC has the adavantage over WAVE of storing metadata.
In Mac OS I prefer AIFF over ALAC or FLAC.

 

[Paul55]

I think AIFF is Wav but with the bytes in a different order. Wav is a specialisation of RIFF, 'Resource Interchange File Format', A is for Apple. They both originate in the mid 80s with the Amiga.

You can put metadata in Wav and it will work by convention. You can also put compressed data into a Wav, it's just a container.

I see no reason not to compress FLAC to the max, the CPU has to do something while it is waiting for the audio output to need filling, it might as well be doing something useful for part of that time.

But, most importantly, do whatever makes you most content.

 

[Lawrence001]

I read that the usual way it's done you can't put music specific metadata into a wav file. I actually considered using wav rather than Flac as the Zen rips to wav then converts and deletes it, but I couldn't find a way to tell it just to stop at the wav and I wanted the album metadata.

 

[tuga]

I think AIFF is Wav but with the bytes in a different order. Wav is a specialisation of RIFF, 'Resource Interchange File Format', A is for Apple. They both originate in the mid 80s with the Amiga.

You can put metadata in Wav and it will work by convention. You can also put compressed data into a Wav, it's just a container.

I see no reason not to compress FLAC to the max, the CPU has to do something while it is waiting for the audio output to need filling, it might as well be doing something useful for part of that time.

But, most importantly, do whatever makes you most content.

It looks like the other way around: WAVE is RIFF/AIFF.

As for compressing, it depends on the DAC's interface's ability to reject noise generated by decompression, which will end up affecting the D/A conversion.
Dedicated/optimised file-playing or streaming hardware uses minimalist OS to minimise processing to the essential, and if the computer is used for upsampling/upconversion/DRC then it is best to use a network-bridge/endpoint as the buffer which feeds the DAC.

Early on the Squeezebox was reported to sound better than non-dedicated computers for this reason, same with the Raspberry Pi. Unlike CD players, computers do not sport adequate grounding and noise is not dealt with adequately.

 

[rdale]

I think AIFF is Wav but with the bytes in a different order. Wav is a specialisation of RIFF, 'Resource Interchange File Format', A is for Apple. They both originate in the mid 80s with the Amiga.

You can put metadata in Wav and it will work by convention. You can also put compressed data into a Wav, it's just a container.

I see no reason not to compress FLAC to the max, the CPU has to do something while it is waiting for the audio output to need filling, it might as well be doing something useful for part of that time.

But, most importantly, do whatever makes you most content.

There are actually two variants of AIFF with the bytes in different orders.

 

[tuga]

Galvanic Isolation
If you isolate the DAC from the computer noise from the computer can’t enter the DAC.
USB power can be pretty dirty.
https://www.thewelltemperedcomputer.com/Intro/SQ/GalvanicIsolation.htm

A bit of noise
“bits are bits” is an opinion often expressed on the audio forums.
As long as the bits are right, everything is right.
(...)
Obvious “bits are bits” is an oversimplification.
The samples are the only part of our digital audio that Is truly digital.
The sample rate is generated by a clock, a analog device with analog imperfection.
Processors and certainly a PC full of all kind of components is a source of noise indeed.
https://www.thewelltemperedcomputer.com/Intro/SQ/SoftwareInducedJitter.htm

EMI/RFI
Wow, a computer is a source of electrical noise by design.
It has bit streams (on/off switching) , high clock speeds, motors (fan, hard disk) and a switched power supply.
Is it possible to get a decent sound out of such noisy environment?
https://thewelltemperedcomputer.com/Intro/SQ/EMIRFI.htm

 

[Paul55]

It looks like the other way around: WAVE is RIFF/AIFF.

As for compressing, it depends on the DAC's interface's ability to reject noise generated by decompression, which will end up affecting the D/A conversion.
Dedicated/optimised file-playing or streaming hardware uses minimalist OS to minimise processing to the essential, and if the computer is used for upsampling/upconversion/DRC then it is best to use a network-bridge/endpoint as the buffer which feeds the DAC.

Early on the Squeezebox was reported to sound better than non-dedicated computers for this reason, same with the Raspberry Pi. Unlike CD players, computers do not sport adequate grounding and noise is not dealt with adequately.

Wav is RIFF storing audio in a file with a wav extension. Not that the detail matters, but the formats are in principle similar. And they can store compressed audio, which will probably cause interesting errors with some replayers.

What does 'noise generated by decompression' mean?

Say a renderer is accessing a resource over the network. It has to operate TCP/IP, it has to operate (for uPnP, IIRC) http, it has to handle demands for rendered audio from some output device. All this involves the CPU doing stuff with a large amount of random responding to the outside world when packets arrive etc. I don't see any systematic argument for making the file transfers bigger in exchange for slightly less data processing to be 'better'. It might be. More likely, IMO, no difference.

I don't recall whether the Squeezebox performed decompression on board or whether it was reserved to the server. It's a real shame that system was discontinued.

 

[tuga]

Wav is RIFF storing audio in a file with a wav extension. Not that the detail matters, but the formats are in principle similar. And they can store compressed audio, which will probably cause interesting errors with some replayers.

What does 'noise generated by decompression' mean?

Say a renderer is accessing a resource over the network. It has to operate TCP/IP, it has to operate (for uPnP, IIRC) http, it has to handle demands for rendered audio from some output device. All this involves the CPU doing stuff with a large amount of random responding to the outside world when packets arrive etc. I don't see any systematic argument for making the file transfers bigger in exchange for slightly less data processing to be 'better'. It might be. More likely, IMO, no difference.

I don't recall whether the Squeezebox performed decompression on board or whether it was reserved to the server. It's a real shame that system was discontinued.

The links I posted earlier all address the issue of "noise" albeit in a very superficial and non-scientific manner. But you will understand what I am referring to.

 

[bencat]

Using the Squeezebox you had an option to either have the decompression completed by the server or the Squeezebox . I fully agree that it is a huge shame that it was discontinued as it offered such a great package in a small and easy to use package when used as a digital source only it was as good as most things in sale today .