IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
NooB: About FLAC kpbs
CC-GoE
post Feb 15 2014, 07:55
Post #1





Group: Members
Posts: 39
Joined: 14-February 14
Member No.: 114480



Dont know if I have to post it here or for the foobar2000.
I just ripped my first CD with foobar2000.
When I played the Audio CD in foobar2000, I saw there at the status bar, CDDA, and something like 1400kpbs.
But after my ripping, I play the flac files, and I see just 350-500kpbs.
Is this normal?
Am I doing something wrong?
Does kpbs in general, show the quality of the audio?
Why is it so low?
Does it depend on the CD in question?
Please help a poor soul...
Go to the top of the page
+Quote Post
testyou
post Feb 15 2014, 08:45
Post #2





Group: Members
Posts: 99
Joined: 24-September 10
Member No.: 84113



The lower file size indicates that your conversion to flac was successful, and your audio was compressed (losslessly).
CD audio is uncompressed, and so take up a lot of space.

No, kpbs does not show quality of the audio, only the disk space it occupies.

This post has been edited by testyou: Feb 15 2014, 08:47
Go to the top of the page
+Quote Post
Octocontrabass
post Feb 15 2014, 08:57
Post #3





Group: Members
Posts: 40
Joined: 9-September 13
Member No.: 110004



"Is this normal?" Yes. Everything is working exactly the way it's supposed to.

"Am I doing something wrong?" It doesn't sound like you've made any mistakes.

"Does kpbs in general, show the quality of the audio?" Nope. That's just a measurement of how much space the audio takes up.

"Why is it so low?" Because FLAC was able to compress it very well.

"Does it depend on the CD in question?" Yes. I've noticed that "quieter" CDs tend to be smaller, but there are exceptions.
Go to the top of the page
+Quote Post
CC-GoE
post Feb 15 2014, 13:22
Post #4





Group: Members
Posts: 39
Joined: 14-February 14
Member No.: 114480



WoW:
Your answers took me completely by surprise.
Until now, I thought, that FLAC, by saying that is lossless, it means that it tries to preserve the kpbs of CDDA, as much as possible.
But your ideas, sound that this is not the case.
Like, FLAC is always lossless, but depending on the CD, it can compress better or worse.
Like, its always the same.
I dont know, I cannot believe you yet.
For me, my idea of this world, says, that smaller the kpbs amount, lower the quality of what I hear.

For the record, my first AudioCD->FLAC, has only some piano and nothing else.
And it got down to 450kpbs.

I did another second AudioCD, which had more music in it, and some vocals.
I got FLACs, which were at about 700kpbs.
I also noticed, that this second FLACs, were very big in size on disk.
Something, not desirable.
Whereas, the first CD, with the 400kpbs. had very small sizes on disk.

EDIT: Something that backs up my view, is the example of the MP3.
I have noticed very clearly, that the MP3 with 320kpbs, is much better quality of 128kpbs.
Isnt that strange?

This post has been edited by CC-GoE: Feb 15 2014, 13:31
Go to the top of the page
+Quote Post
Neuron
post Feb 15 2014, 13:43
Post #5





Group: Members
Posts: 143
Joined: 14-December 12
Member No.: 105171



God, please not this again...

Let me put it this way. Some files can be compressed to less than half their size by ZIP, 7z or RAR compression. Does that mean you lose letters from your term paper when you compress it with WinRAR? Are "less important" parts of your document thrown out? Of course not.

Imagine a simpler example, a document made only of 40 zeros, 51 ones and 200 threes. The uncompressed version will write each number seperately written down, the losslessly compressed one will just contain an instruction "write down 40 zeroes, 51 ones and 200 threes".

Lossless compression codes the redundant parts of the audio signal more efficiently. If FLAC was 1411 kbps, then it would be totally useless as it is supposed to losslessly reduce the space the sound occupies. There is already a format that has "all the kbps", it is called WAV and offers ZERO advantage over FLAC. FLAC files are decompressed while playing and the result is a bit identical copy of the original audio. You can check it using foobar's bit comparator.

By coding redundancy, you can reduce a file 1411 kbps file to 300-1100 kbps, depending on source material. Piano is usually quiet, with huge "empty spaces" and a good dynamic range which means it can be compressed efficiently.

As a side note, I will never understand the obsession with "kbps". It is funny how back when all mp3 encoders were shit and produced warbly, pre-echo filled files even at 320 kbps everybody was happy with 128 kbps yet nowadays everyone wants MORE KBPS even through modern mp3 encoders produce better quality at 128 kbps than the old ones at 320 kbps.
Go to the top of the page
+Quote Post
probedb
post Feb 15 2014, 14:05
Post #6





Group: Members
Posts: 1194
Joined: 6-September 04
Member No.: 16817



There was a post with exactly the same question not 2 weeks ago.

Also you need to backup "I have noticed very clearly, that the MP3 with 320kpbs, is much better quality of 128kpbs." with some ABX and the TOS you agreed to when you joined.
Go to the top of the page
+Quote Post
CC-GoE
post Feb 15 2014, 14:25
Post #7





Group: Members
Posts: 39
Joined: 14-February 14
Member No.: 114480



QUOTE (probedb @ Feb 15 2014, 15:05) *
...the MP3 with 320kpbs, ... of 128kpbs." with some ABX and the TOS you agreed to when you joined.


Ups, for starters I am sorry. I wrote them all wrong. Its kbps and not kpbs.

Your answers were very nice.
I got some ideas. In particular, the one that says, that when I compress with ZIP or 7z, I never actually "lose" any part of the document.
I can uncompress it, and it will come back the same.

On the sidenote, do you ppl, know if the compression ratio setting, 0-8, has any danger lurking afterwards, when playing the FLACs etc?
Or is it just, that with 8 I wait a little bit more, for the generation of the FLACs and thats it?
BTW I tested, my first AudioCD, the one with only piano, with 5 and 8 ration, and I noticed very small difference in size.
I dont know though, what would happen if I tried with the second CD. I probably should try.
But you know, if the 8 setting, has some effect on my WIN PC, and it can break when I play FLAC, then I will leave it to the default 5.
Go to the top of the page
+Quote Post
Neuron
post Feb 15 2014, 14:28
Post #8





Group: Members
Posts: 143
Joined: 14-December 12
Member No.: 105171



Some portables have problems with FLAC 8 and it requires a lot more power to decode, so it is recommended to use FLAC 5. All FLAC levels are equally lossless, it is just that the highest levels take a lot more processing power to encode and decode with little size benefit. But no, it will not damage your PC.

And probedb is not making a fuzz about grammar. The thing is, this is an "objectivist" audiophile forum so any claim about sound quality has to be proven by ABX tests (except for lossless vs lossless which are the same by definion regardless of format). I agree that a random 128 kbps mp3 from the Internet encoded by god know what encoder will most likely sound worse than a 320 kbps LAME encode that you made on your own from a CD, but the mp3 format is not to be judged by random pirate mp3s anymore than cassettes were to be judged by shortwave radio recordings on cheap cassettes made 30 years ago. A well made V5 LAME encoding (VBR bitrate around 128 kbps, but as it is VBR it can go higher or lower as it needs) can sound transparent to many people.

This post has been edited by Neuron: Feb 15 2014, 14:34
Go to the top of the page
+Quote Post
Porcus
post Feb 15 2014, 14:33
Post #9





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



QUOTE (CC-GoE @ Feb 15 2014, 14:25) *
On the sidenote, do you ppl, know if the compression ratio setting, 0-8, has any danger lurking afterwards, when playing the FLACs etc?
Or is it just, that with 8 I wait a little bit more, for the generation of the FLACs and thats it?


Yes, that's it. -8 and -5 and -0 will decode at approximately the same computer load; -8 is at most only slightly more taxing on CPU, and often that is more than compensated by faster reading from hard drive (since it is a smaller file).

Not all codecs have this property, but FLAC was optimized for decoding speed, not for the most extreme compression.


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
CC-GoE
post Feb 15 2014, 14:35
Post #10





Group: Members
Posts: 39
Joined: 14-February 14
Member No.: 114480



...I would like to make a test case with this "foobar BIT comparator".
But I dont have the slightest clue how to use it.
I will try to read it though...
It says: I compare 2 files and see the differences.
But which 2 files do you mean that I have to test?
I mean OK I have one FLAC say that I ripped from the CDDA.
With which one should I test it with?
With the CDDA? Haha...
Go to the top of the page
+Quote Post
lvqcl
post Feb 15 2014, 14:41
Post #11





Group: Developer
Posts: 3328
Joined: 2-December 07
Member No.: 49183



QUOTE (Neuron @ Feb 15 2014, 17:28) *
Some portable have problems with FLAC 8 and it requires a lot more power to decode

?? The difference in decoding speed between FLAC -5 and -8 is very small. Examples from http://www.rockbox.org/wiki/CodecPerformanceComparison:

Portal Player (ARM7TDMI):
flac -5: 695.53% realtime
flac -8: 652.44% realtime

Samsung S3C2440AL-30 (ARM920T):
flac -5: 2137.30% realtime
flac -8: 2047.72% realtime

This post has been edited by lvqcl: Feb 15 2014, 14:43
Go to the top of the page
+Quote Post
Porcus
post Feb 15 2014, 14:42
Post #12





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



Edit: too slow :-o


QUOTE (Neuron @ Feb 15 2014, 14:28) *
Some portables have problems with FLAC 8 and it requires a lot more power to decode, so it is recommended to use FLAC 5.


?

Four percent difference according to http://synthetic-soul.co.uk/comparison/los...Rate&Desc=1 .
See also https://xiph.org/flac/comparison.html .


If you use the --lax switch, you can end up outside the streamable subset, but who uses that?

This post has been edited by Porcus: Feb 15 2014, 14:43


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
Porcus
post Feb 15 2014, 14:51
Post #13





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



QUOTE (CC-GoE @ Feb 15 2014, 14:35) *
...I would like to make a test case with this "foobar BIT comparator".


It works this way: you highlight two files and ask to compare; it decodes and reports whether there is any difference and if so "how much".

-> You will not use this to check if two rips are the same; good CD rippers give you a checksum, and if you rip twice you will see whether they match (in EAC there is a test-and-copy functionality, in dBpoweramp the checksum turns green if you rip twice and get the same).

-> You will not use this to verify a FLAC encoding, you use a -V or --verify (those are synonyms, beware the capital V) - then the encoder will first encode, and then decode and compare to the original signal.

-> You will not use this to compare two FLACs encoded at different settings - using verification grants that they are both identical to the original signal, hence they are identical to each other too.


What you could have use for, is fb2k's verify integrity command. The FLAC encoder writes a checksum to metadata, so if the audio fails to match that, it will tell you that the file is corrupted.

This post has been edited by Porcus: Feb 15 2014, 14:51


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
mjb2006
post Feb 15 2014, 15:08
Post #14





Group: Members
Posts: 755
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



Partially restating what has been said, bitrate measures efficiency of the compression; it's just how much space the audio takes up, divided by the play time. One or both of those numbers may be rough estimates.

foobar2000 estimates the overall bitrate of a FLAC by looking at the total file size and the duration of the audio. Example:
  • file size: 12 million bytes @ 8 bits per byte = 96 million bits
  • duration: 2 minutes = 120 seconds
  • bitrate: 96000000 bits 120 seconds = 800000 bits per second = 800 kilobits per second (kbps)

A small part of the FLAC is normally taken up by non-audio info: the tags. They are included in the file size, so it makes the overall bitrate estimate slightly higher than if we just looked at the audio data. If large images are embedded in the tags, it can really bloat the bitrate. Of course that doesn't mean anything has changed in the audio data; it has the same bitrate as before. It just means the file is bigger.

foobar2000 might estimate the bitrates of files in other formats (like MP3) with greater precision, because tags are ignored or the file itself says what the bitrate is.

Another consideration is that during playback of FLAC or any other VBR format, the actual (not estimated) bitrate fluctuates many times per second, as some segments of audio could be compressed better than others. If you play a VBR MP3, you can see the bitrate updating at the bottom of the foobar window. There's an Advanced display preference for how many updates per second it does.

Knowing the bitrate is useful when you are streaming, i.e. sending the file over a network, and the receiver is playing it as it comes in. The network bandwidth has to exceed the audio bitrate or they won't be able to receive it fast enough to listen to it uninterrupted, buffering notwithstanding.

This post has been edited by mjb2006: Feb 15 2014, 15:14
Go to the top of the page
+Quote Post
Frank Bicking
post Feb 16 2014, 08:48
Post #15





Group: Super Moderator
Posts: 1827
Joined: 24-July 02
Member No.: 2776



Thread split: FLAC tags in Windows Explorer
Go to the top of the page
+Quote Post
CC-GoE
post Feb 16 2014, 08:58
Post #16





Group: Members
Posts: 39
Joined: 14-February 14
Member No.: 114480



QUOTE (mjb2006 @ Feb 15 2014, 16:08) *
Partially restating what has been said, bitrate measures efficiency of the compression; it's just how much space the audio takes up, divided by the play time. One or both of those numbers may be rough estimates.

foobar2000 estimates the overall bitrate of a FLAC by looking at the total file size and the duration of the audio. Example:
  • file size: 12 million bytes @ 8 bits per byte = 96 million bits
  • duration: 2 minutes = 120 seconds
  • bitrate: 96000000 bits 120 seconds = 800000 bits per second = 800 kilobits per second (kbps)

A small part of the FLAC is normally taken up by non-audio info: the tags. They are included in the file size, so it makes the overall bitrate estimate slightly higher than if we just looked at the audio data. If large images are embedded in the tags, it can really bloat the bitrate. Of course that doesn't mean anything has changed in the audio data; it has the same bitrate as before. It just means the file is bigger.

foobar2000 might estimate the bitrates of files in other formats (like MP3) with greater precision, because tags are ignored or the file itself says what the bitrate is.

Another consideration is that during playback of FLAC or any other VBR format, the actual (not estimated) bitrate fluctuates many times per second, as some segments of audio could be compressed better than others. If you play a VBR MP3, you can see the bitrate updating at the bottom of the foobar window. There's an Advanced display preference for how many updates per second it does.

Knowing the bitrate is useful when you are streaming, i.e. sending the file over a network, and the receiver is playing it as it comes in. The network bandwidth has to exceed the audio bitrate or they won't be able to receive it fast enough to listen to it uninterrupted, buffering notwithstanding.


WoW:
That rocked my world...
Go to the top of the page
+Quote Post
probedb
post Feb 16 2014, 10:45
Post #17





Group: Members
Posts: 1194
Joined: 6-September 04
Member No.: 16817



QUOTE (Neuron @ Feb 15 2014, 13:28) *
Some portables have problems with FLAC 8 and it requires a lot more power to decode, so it is recommended to use FLAC 5.


Maybe in the land before time forgot. I've had my Clip+ for a number of years and all my stuff is at 8. Never had any issues.
Go to the top of the page
+Quote Post
detmek
post Feb 16 2014, 11:39
Post #18





Group: Members
Posts: 63
Joined: 24-June 08
Member No.: 54802



QUOTE (Porcus @ Feb 15 2014, 15:51) *
-> You will not use this to check if two rips are the same; good CD rippers give you a checksum, and if you rip twice you will see whether they match (in EAC there is a test-and-copy functionality, in dBpoweramp the checksum turns green if you rip twice and get the same).

-> You will not use this to verify a FLAC encoding, you use a -V or --verify (those are synonyms, beware the capital V) - then the encoder will first encode, and then decode and compare to the original signal.

-> You will not use this to compare two FLACs encoded at different settings - using verification grants that they are both identical to the original signal, hence they are identical to each other too.


What you could have use for, is fb2k's verify integrity command. The FLAC encoder writes a checksum to metadata, so if the audio fails to match that, it will tell you that the file is corrupted.

Why not?
1. If I don't have checksums (I already ripped files and didn't kept logs) I can use bitcompare to see if both rips decode into same PCM.
2. Agree with that. No problem.
3. Decoding two FLAC files encoded at different settings will confirm that output is identical. This is also test for foobar's decoder. If 2 FLAC files encoded at different settings are not matched after decoding then there is a problem with encoding or decoding.
Edit:
When I wrote above, I had flac's verify in mind. Foobar's verify also uses foobar's decoder. But, since Verify and BitCompare must decode files into PCM, with a difference that Verify calculates CRC and BitCompare compares bits, both plugins do same thing in the end.

This post has been edited by detmek: Feb 16 2014, 11:58
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 25th July 2014 - 18:04