HydrogenAudio

Hi :)

sorry for the stupid question but I would like to convert my CDs with Flac, therefore without quality loss. I downloaded them all and I seem to have set everything correctly but I don't understand why there are various types of compression for the flac which, if I understand correctly, should have the same quality as the CD. Can you tell me what I need to set in EAC to have the best quality? Thank you :)

Flac is lossless, so there is no 'best' quality when you choose to use that. The defaults in EAC will do fine if this is all new to you. The only difference is a slightly smaller (or bigger) file when tweaking the Flac compression options. Smaller files will take more time to encode, that's basically it.

sorry but isn't that strange? :)
So what does the larger file contain in extra space? :) I imagine that in that used space there is information that is excluded with a smaller bitrate.
And then I see many sites that offer Flac with different bitrates as if it were obvious that the quality improves with the higher bitrate

Suppose you got a text file that contains nothing but a billion blank spaces.
It is possible to compress that file into a smaller one without loss of information - indeed, the previous sentence just described the information content in a much shorter manner.

That is what compressed formats like .zip do to ordinary files, and what lossless compressors like FLAC do to audio.
Why not use zip for audio? Because it is not very efficient. Audio compressors take advantage of how typical sounds behave.

As was said, FLAC is lossless which means that the audio that goes in is identical to what comes out. You can tell FLAC to work harder to compress a little bit better, but the difference might just be 1%.

When FLAC files are offered at different bitrates, the difference is probably not the FLAC settings used to encode. Instead, especially if the differences are large, they are because the original audio is higher resolution than CDs (e.g., 24 bits, or higher sample rates, or more channels). FLAC will losslessly compress these files also to varying degrees, but the differences from the higher resolutions will remain (because there's more information in the higher resolution files).

For your CD encoding, you do not have access to higher resolution versions, so the differences between the FLAC settings will be small.
 

mine are old CDs, so not those recorded with new technology. However, it remains strange because if there are 24bit CDs, a Lossless compression format should not lose anything and therefore, despite your help, I cannot explain why we are talking about different bitrates when the copy should be identical.

And, if you tell me about "minimal differences" it means that there could be some differences, so why not use the settings to bring out the best from my CDs?

And then, if the compression is better you should obtain a smaller file, however when the compression is slower you obtain, if I understand correctly, larger files. So there must be something in that larger space :)

That said, I don't want to bore you. Bear in mind that they are rare CDs that will not be reissued and I am afraid that they will be damaged, so please advise me on what to do.

Thanks :)

However, it remains strange because if there are 24bit CDs

No, a 24 CD don't exist. The Redbook standard is always 2 channel PCM audio with a 16 bit sample and a 44.1 kHz sample rate.

FLAC has a compression level ranging from 0 tom 8
This "compression" parameter is a permanent source of misunderstanding.
A lot of people thing that it works like the bit rates in MP3 so higher compression is more loss.

FLAC compression parameter simply tells how many CPU FLAC is allowed to use to find the best possible linear prediction. The better the prediction, the lower the residue will be hence a smaller file.
When Josh Coalson started the development of FLAC in 2000 this parameter made sense (remember all those PC's to small to run XP?)
With today’s CPU’s you probably won’t notice the difference in time between e.g. 0 and 8.

Once again, regardless of the compression ratio chosen, the result is always lossless.

no, I think that if a file is larger and takes longer to generate (is that right?), that file must contain something more, otherwise there is no point in wasting more time and having a larger file.

Maybe I'm unclear. I'll give you an example. If I have 100 objects to put in a drawer, if I do it quickly, I can fit them in but they take up all the space because they are messy. So

less time = large size

If I take more time, I optimize the space and therefore, I should have some space left over in the drawer. So

more time = smaller size

On the other hand, 24bit files or other types of compressions found online generate much larger files and contradicts the reasoning I made above. I hope I explained myself :)

no, I think that if a file is larger and takes longer to generate (is that right?), that file must contain something more, otherwise there is no point in wasting more time and having a larger file.

You need to think more precisely about what is "larger". Yes handling a bigger file takes more effort, but that is different than the compression algorithm:
* If you have more data to process, it will take more time to process and the output will be larger.
* If you start with the same data but want to pack it tighter (that is, smaller file in the end), you need to invest more effort in the job.

Look at the attachment. I started with a file called "empty", which just takes up
9 876 543 210 bytes of ... nothing. Yes, close to ten GB. Then I used Windows' send to zip. That compressed it and put it into emptyfile1.zip which is
9 599 747 bytes. Less than 1/1000 of the original, spent describing what the big one is. But it could have been packed tighter, and that is what I did. I used send to zip again, that compressed it and put it into emptyfile2.zip, which is
15 641 bytes. Those bytes describe how emptyfile1.zip was packed tighter and into what. I did it once more, and got the
964 bytes that you see attached.

Typically, doing this over again won't help - it is simply because I created something with a lot of thin air in it. Handling this - uploading it to you, and downloading it on your side - doesn't take much resources, because the compressed file is small.
But getting it so small took more effort.

Now, there is a limit to how small a given source file can be.  If each bit is just independently drawn (with equal probability), then you cannot do anything to get it smaller. But this attachment has very little content.

Instead I downloaded flacs of the same song that are twice as big as the others

If you buy a download of this piece of music vs that piece of music, they are of different size for the same reason as "independently drawn" takes up more size than "empty files".
The most extreme would be silence. That can in principle be compressed down to very little, just like the attachment - although some of the algorithms were not developed to catch it, so they don't do it well. I actually tested it: https://hydrogenaud.io/index.php/topic,122413.0.html

But, ... read: https://en.wikipedia.org/wiki/Lossless_compression

sorry but I didn't understand (bad English), can you tell me if the drawer example is right or not?

Sorry, I did not see your update.

* Your drawer example is quite good.

* But the difference between 16 bit and 24 bit is like the difference between a shirt and a jacket: Even if you spend more time packing the jacket down, it will take more space.

I don't know anything about 16 or 24. The way I see it, the CDs I need to convert are the items I need to put in the drawers. If we take more time to insert them it is obvious that we do it because we obtain a better file, it would not make sense to waste time for nothing.

Your CDs, as previously stated, are 16-bit at 44.1KHz, it doesn't matter whether they were recorded in 1982 or 2024, a CD is a CD.

The drawer example is OK, but you're not trying to fit anything into a fixed size. For example, a 1 minute track on a CD will always take up the same amount of raw data but it depends what that data is as to how it compresses with FLAC. I.e. in incredible simplistic terms, 1234 takes the same amount of space as 5555, but there is a lot of repetition in the second example so it can take up less space that the first.

no, I think that if a file is larger and takes longer to generate (is that right?), that file must contain something more, otherwise there is no point in wasting more time and having a larger file.

Maybe I'm unclear. I'll give you an example. If I have 100 objects to put in a drawer, if I do it quickly, I can fit them in but they take up all the space because they are messy. So

less time = large size

If I take more time, I optimize the space and therefore, I should have some space left over in the drawer. So

more time = smaller size

On the other hand, 24bit files or other types of compressions found online generate much larger files and contradicts the reasoning I made above. I hope I explained myself :)

You have it backwards, and I’m not sure why nobody is correcting you in a clear manner.

The compression settings that take longer to compress, result in a smaller file. Not larger.

They still decompress to the same audio data. The benefit of spending more time/processor power upon encode would be slightly smaller files.



As for your initial question, about the bitrate settings in EAC - I am not sure why nobody appears to have picked up on this either. You are specifically asking about the bitrate settings in this one program.

Whoosh!

Those settings are not applicable to FLAC, they are intended to configure some of the built in MP3 encoders. Most of those settings are completely ignored by the FLAC encoder, it’s the command line instructions that do all the work. Simply leave those settings at their defaults.

Doesn't EAC still have a "bitrate" setting?

For lossless, ignore that.

When the 'Parameter passing scheme' is set to 'User Defined Encoder' (as is necessary to use the FLAC encoder) the 'Bit rate' and 'Quality' settings are ignored.
https://wiki.hydrogenaud.io/index.php?title=EAC_and_FLAC

Spoiler (click to show/hide)

Quote from: LauraQ on 2024-03-17 18:59:00

no, I think that if a file is larger and takes longer to generate (is that right?), that file must contain something more, otherwise there is no point in wasting more time and having a larger file.

Maybe I'm unclear. I'll give you an example. If I have 100 objects to put in a drawer, if I do it quickly, I can fit them in but they take up all the space because they are messy. So

less time = large size

If I take more time, I optimize the space and therefore, I should have some space left over in the drawer. So

more time = smaller size

On the other hand, 24bit files or other types of compressions found online generate much larger files and contradicts the reasoning I made above. I hope I explained myself :)

You have it backwards, and I’m not sure why nobody is correcting you in a clear manner.

The compression settings that take longer to compress, result in a smaller file. Not larger.

They still decompress to the same audio data. The benefit of spending more time/processor power upon encode would be slightly smaller files.



As for your initial question, about the bitrate settings in EAC - I am not sure why nobody appears to have picked up on this either. You are specifically asking about the bitrate settings in this one program.

Whoosh!

Those settings are not applicable to FLAC, they are intended to configure some of the built in MP3 encoders. Most of those settings are completely ignored by the FLAC encoder, it’s the command line instructions that do all the work. Simply leave those settings at their defaults.

It's probably me who understands badly and they are patient in explaining it to me :)

so, if I understand correctly, you are telling me that if a flac is smaller it is because it was compressed more and therefore it took longer to create it?
And therefore, two identical songs converted to flac with the command you gave me

-8 -V -T "Artist=%artist%" -T "Title=%title%" -T "Album=%albumtitle%" -T "DATE=%year%" -T "TRACKNUMBER=%tracknr%" - T "Genre=%genre%" -T "ALBUMARTIST=%albumartist%" -T "ALBUM ARTIST=%albumartist%" -T "COMMENT=EAC Secure Mode, Test & Copy, AccurateRip, FLAC -8" %source%

and I change the 8 with the 1, do I have the same quality but simply bigger files?

and I change the 8 with the 1, do I have the same quality but simply bigger files?

Yes.
Precisely the same audio - only in a bigger drawer.

Quote from: LauraQ on 2024-03-17 23:17:19

and I change the 8 with the 1, do I have the same quality but simply bigger files?

Yes.
Precisely the same audio - only in a bigger drawer.

Thanks, now everything is clear though, as @Korth (thanks) posted from wiki
"values aren't very useful in the FLAC command-line options."
I don't think there's much clarity on the subject :)


EDIT

OMG. I clicked in EAC Test decoder and it gives me 839

now I see on the internet that they say that the best bitrate is 1,411kbps

I don't understand anything anymore :(

1411 is for WAVE, that is, uncompressed.

839 in .flac looks reasonable. Yes, for precisely the same audio.
(There is a lot of air in the WAVE drawer!)

Edit: When you try a different CD, it will give a different FLAC bitrate. Because not everything can be packed equally tightly.

Google's first response says:

"Lossless audio formats such as WAV, FLAC, or ALAC preserve audio data and, therefore, will require higher bitrates to retain audio quality. Bitrates of 1,411kbps and above are best suited for lossless audio formats"

so they don't just talk about Wave

and then, why on earth would Wave keep empty space in the drawer? :)

and 1400 is almost double 800. what will it be in there?????
OMGGGG ^_^

WAVE is uncompressed. Just like what you would get if you unpacked everything in that .zip file I attached - then you would get ten GB of "nothing", taking taking up 10 GB on your hard drive.
FLAC is lossless, but compressed. Just like .zip on your text files.

Why WAVE saves "empty space"? It isn't done deliberately.  The files have each sample in order, the way they are sent to your digital/audio converter. The WAVE file contains a few bytes saying "here is what I am and what I contain", and then ("2" because of the "16" bits):
2 bytes for the first sample of the left channel, 2 bytes for the first sample of the right channel
2 bytes for the next sample of the left channel, 2 bytes for the next sample of the right channel
etc.

FLAC stores them in a different way - and to get those samples back, one has to do a few calculations. That is the "decoding". Even a twenty year old computer can do that pretty quick.

And yes, unless the CD is white noise at full volume, there will be some compressible space in there.
For reference, my classical music compresses to 45 percent of WAVE size. The rest of my CD collection - lots of metal - averages to around 65 percent of WAVE size.

But you can rest assured that FLAC keeps precisely the same audio. You see the "-V" after "-8" on that line? That tells FLAC to verify, and it does that as follows:
When the encoder has made the .flac file from uncompressed audio, it will decode the flac file; then it has a second copy of uncompressed audio. They should be equal. And they will be compared, bit by bit, to make sure that they indeed are equal.

"values aren't very useful in the FLAC command-line options."
I don't think there's much clarity on the subject :)

There's a reason I hid that behind a spoiler.
%bitrate% is a placeholder that can be used to transfer a selected value from 'Bit rate' to the command-line.
'Bit rate' values are a set of fixed numbers ranging from 32 to 1024.
In the FLAC command-line options you're using -8 (available values for that parameter are -0 through -8).
Values that are fixed numbers ranging from 32 to 1024 aren't very useful when the only numbers you can use are 0-8.

Sorry but I'm still confused :(

Then, even if I wanted to compress my flacs to 1.411 I couldn't do it because, I tried with Eac, without inserting the CD, the decoder test and if I change from 8 to 6, it always gives me 839. So I don't know what program they have used to get to 1,411 and what settings they used and, above all, why they do it since it makes no sense to add data when it should already all be there.

What I read on the Internet does not speak of greater or lesser compression, which would be trivial, but of increased or decreased bitrates, therefore of data that is taken from the CD and if 1.411 can be taken it means that that data exists and is there the possibility of doing so is that more data can be extracted than the 839 that EAC extracts from me

Quote from: LauraQ on 2024-03-17 23:46:21

"values aren't very useful in the FLAC command-line options."
I don't think there's much clarity on the subject :)

There's a reason I hid that behind a spoiler.
%bitrate% is a placeholder that can be used to transfer a selected value from 'Bit rate' to the command-line.
'Bit rate' values are a set of fixed numbers ranging from 32 to 1024.
In the FLAC command-line options you're using -8 (available values for that parameter are -0 through -8).
Values that are fixed numbers ranging from 32 to 1024 aren't very useful when the only numbers you can use are 0-8.

therefore it is not true that all the data are extracted but only those that are considered audible. But I see many articles that talk about the importance of having the highest bitrate because it is not clear what and how much the human ear can perceive. This is why we talk about bitrate. If all this were not going on, no one would have talked about it. We would only be talking about a complete copy of data to which you can decide whether to compress it more or less

from the CD and if 1.411 can be taken it means that that data exists and is there the possibility of doing so is that more data can be extracted than the 839 that EAC extracts from me

EAC reads 1411 from the CD.
Then it packs them into fewer using FLAC.
Still the same audio.

I was looking at the EAC settings and I didn't realize that I had set the bitrate to 896. Now I put it at 1024 which, by the way, is not the 1.411 I was talking about. And the fact that there is a Bitrate item to be set in EAC, even though I have set User Defined encoder and put the flac and the Bitrate item is active, tells me that you can decide how much data to extract from the CD and this clashes with the concept of Lossless.
But sorry, I see many articles by people who discuss what the human ear can perceive and therefore high bitrates must be used, the EAC options allow it, Google recommends using bitrates and you all tell me that it's not necessary.
I'm confused because everything I find online tells me one thing and you here (who are very expert and very kind obviously) tell me the opposite

I was looking at the EAC settings and I didn't realize that I had set the bitrate to

We have already - more than once - tried to educate you to ignore that when you let EAC encode to FLAC.

tells me that you can decide how much data to extract from the CD

We have already tried to educate you that this is now how it works when you let EAC encode to FLAC.

I suggest you set EAC to write to WAVE instead. Inconvenient for you, but better for those who have volunteered to try to make you wiser. I give up.

this clashes with the concept of Lossless.

Please do a simple test. Take a text file, zip it and then take a jpg file and zip it. One of them will achieve a much greater compression ratio than the others, but after unzipping them they will both be exactly the same as before. The same happens with flac. Flac does never throw away any information, no matter what the resulting bitrate will be.

You are still clearly confused. Think of a 'zip' file. You zip data - text, images, etc, and you end up with a much smaller file. It has been compressed. When you unzip the file you get back exactly what you started with - it was compressed losslessly. Because of the nature of audio data, standard 'zip' file techniques do not work, they compress very little. FLAC, WavPack, Monkeys Audio, and others, are able to analyse the audio data and compress it without losing any of it. In terms of quality, the quoted bitrate of these compressed files has no meaning. If you decompress a FLAC, WavPack, etc, file you will get back exactly the same audio data that you started with. If you play a wav file, a FLAC file, etc, in a digital audio player such as foobar2000, you will hear exactly the same output. What you say regarding "only those that are considered audible" is effectively how techniques like mp3 work. These are 'lossy' formats. The audio data is analysed, very often with the use of a 'psychoacoustic model', which mimics how we hear sounds, and discards parts of the 'total' sound that it considers the listener won't miss. In this case bitrate is quite critical as it determines how much of the original audio data has been discarded.

I hope the above helps clarify things for you.

I was looking at the EAC settings and I didn't realize that I had set the bitrate to 896. Now I put it at 1024 which, by the way, is not the 1.411 I was talking about.

The bitrate setting in EAC has no effect to the FLAC compression - this is just for calculating/showing the estimated size of the compressed file. Check it out and set it to 32k - you will see the saved track has the same size as for 1024k.

FLAC is like ZIP - it compress losslessly. The FLAC compression settings (-0 to -8) just control the computing effort and therefore the resulting size of the compressd file - its NOT the quality - its still lossless like ZIP. The decompressed file is exactly the same as the input file - thats the way how ZIP and FLAC work.

The 1.411k is the original uncompressed bitrate on the CD. FLAC will compress it as good as possible.

The compression setting -0 is fast and give you larger file compared to -8. The setting -8 takes longer to compute and the file will be smaller. Decompressed still exactly (100%) the same as the original.

You are still clearly confused. Think of a 'zip' file. You zip data - text, images, etc, and you end up with a much smaller file. It has been compressed. When you unzip the file you get back exactly what you started with - it was compressed losslessly. Because of the nature of audio data, standard 'zip' file techniques do not work, they compress very little. FLAC, WavPack, Monkeys Audio, and others, are able to analyse the audio data and compress it without losing any of it. In terms of quality, the quoted bitrate of these compressed files has no meaning. If you decompress a FLAC, WavPack, etc, file you will get back exactly the same audio data that you started with. If you play a wav file, a FLAC file, etc, in a digital audio player such as foobar2000, you will hear exactly the same output. What you say regarding "only those that are considered audible" is effectively how techniques like mp3 work. These are 'lossy' formats. The audio data is analysed, very often with the use of a 'psychoacoustic model', which mimics how we hear sounds, and discards parts of the 'total' sound that it considers the listener won't miss. In this case bitrate is quite critical as it determines how much of the original audio data has been discarded.

I hope the above helps clarify things for you.

but I understand perfectly what you are saying. I'm just telling you that the Internet is full of articles that say the opposite :)

If the issue was just compression, well EAC wouldn't leave the bitrate option active when you set the flac, Google wouldn't recommend using high bitrates for flac, as I posted and there wouldn't be so many articles from people saying that it doesn't all data is extracted and therefore it is necessary to use high bitrates.

but I understand perfectly what you are saying. I'm just telling you that the Internet is full of articles that say the opposite :)

hydrogenaudio also is "internet". It is full of articles that say exactly what has been tried to teach you.

If the issue was just compression, well EAC wouldn't leave the bitrate option active when you set the flac, Google wouldn't recommend using high bitrates for flac, as I posted and there wouldn't be so many articles from people saying that it doesn't all data is extracted and therefore it is necessary to use high bitrates.

It is impossible to set a fixed bitrate for lossless compression, be it zip, 7zip, flac, tak, ape etc.
The result fully depends on the complexity of the source. If eac lets you choose a bitrate for flac, this is wrong and should be fixed.

When the 'Parameter passing scheme' is set to 'User Defined Encoder' (as is necessary to use the FLAC encoder) the 'Bit rate' and 'Quality' settings are ignored.

The bitrate setting in EAC has no effect to the FLAC compression - this is just for calculating/showing the estimated size of the compressed file. Check it out and set it to 32k - you will see the saved track has the same size as for 1024k.

but I understand perfectly what you are saying. I'm just telling you that the Internet is full of articles that say the opposite :)

The internet is also full of articles about the "Flat Earth theory" and the "Moon landing conspirancy".

If the issue was just compression, well EAC wouldn't leave the bitrate option active when you set the flac, Google wouldn't recommend using high bitrates for flac, as I posted and there wouldn't be so many articles from people saying that it doesn't all data is extracted and therefore it is necessary to use high bitrates.

I'm sorry, but you are being distracted by people who really have no idea what they are talking about. If you don't believe us at HA, conduct your own tests, the data does not lie.

Quote from: LauraQ on 2024-03-18 11:26:39

but I understand perfectly what you are saying. I'm just telling you that the Internet is full of articles that say the opposite :)

hydrogenaudio also is "internet". It is full of articles that say exactly what has been tried to teach you.

Quote from: LauraQ on 2024-03-18 11:26:39

If the issue was just compression, well EAC wouldn't leave the bitrate option active when you set the flac, Google wouldn't recommend using high bitrates for flac, as I posted and there wouldn't be so many articles from people saying that it doesn't all data is extracted and therefore it is necessary to use high bitrates.

It is impossible to set a fixed bitrate for lossless compression, be it zip, 7zip, flac, tak, ape etc.
The result fully depends on the complexity of the source. If eac lets you choose a bitrate for flac, this is wrong and should be fixed.

my doubts come precisely from these oddities. I was wondering why EAC, which, I assume, is written by very expert people and controlled by millions of people, leaves a function active when it shouldn't be and misleads so many people?
But I understand that I raise doubts that you don't have and, reading above, I already understand that I have bored you enough.
So I thank everyone for the help and... obviously I ONLY trust what you recommend, otherwise I wouldn't be here ;)

Thanks for all ^_^

The 'External Compression' tab doesn't know what 'User Defined Encoder' you're using. It's well uh 'user defined'.
The EAC configuration wizard can setup FLAC for you but the encoder is still considered 'user defined'. It is not a preset.

The options 'Bit rate' and 'Quality' are ignored when using 'User Defined Encoder'. As %bitrate% or %islow%...%islow% and '%ishigh%...%ishigh% can be added to the command-line to make use of these otherwise ignored settings, the options cannot be grayed-out or disabled.

Below link shows examples using %bitrate% or %islow%...%islow% and '%ishigh%...%ishigh% in the command-line with the LAME mp3 encoder set as 'User Defined Encoder'.
https://wiki.hydrogenaud.io/index.php?title=EAC_and_Lame#Advanced_Command_Line_Usage

all clear, thanks :)

I love your drawer analogy!!!   If you work harder and take more time, the stuff takes-up less space!

CDs are 16 bits x 44.1K samples per second x 2 channels =1411kilobits per second.  There are 8-bits in a byte so that's 176 kilobytes per second, or about 10MB per minute. 

You can rip a CD to wave with the same settings and the data is identical (with an identical bitrate), but in a WAV container.

Uncompressed 24-bit files are 50% bigger.   48kHz files are about 10% bigger.  (not including any embedded artwork.)

The same ratios approximately carry-over to FLAC files.  A 24-bit FLAC is about 50% bigger than a 16-bit copy of the same file.  But FLAC is "smart" and if you make a 24-bit FLAC from a 16-bit original it will be the same size as a 16-bit FLAC.   Or if you have a "mono" CD* with the same audio in both channels it will be about half the size of a true-stereo FLAC.

Some audio compresses easier than others, so with the same FLAC setting different files can give you different bitrates.  I've never tried making a silent FLAC but I'm sure it has a low bitrate.

*CDs are always 2-channels.   It's the only format I know of with that limitation.   A mono (1-channel) file will play through both speakers.

everything is clear and I'm glad you liked my example with the drawer ^_^