Menu
▾
▴
1 Attachments
#151 Uncompressed FLAC still compressed with HDCD
Hi
I'm trying to do the following using DBPowerAmp, but the same seems to apply to other ripping tools.
Aim:
to rip HDCDs to 20-bit format. 20-bit is not supported so as such the resulting FLAC is a 24-bit with the last 4 bits padded out with zeros. However, when doing this to create uncompressed FLAC, the resulting file actually still is compressed.
Steps to reproduce:
- use a HDCD like Bee Gees - their greatest hits.
- rip the CD in DBPowerAmp (DPA) or EAC (using --disable-constant-subframes --disable-fixed-subframes --max-lpc-order=0 as parameters)
- verify the metadata. The sample rate is 24bits and there is a 30% compression applied eventhough compression was disabled.
I verified this by upsampling a 16bit file to 24 bit. In this case, the new file is 24 bit but with zero compression. It seems that the 20 bit format is a problem and the padded zeros are still compressed eventhough this should not happen.
What is going wrong here?
Uncompressed FLAC is something dBpowerAmp invented, it is not supported by the FLAC project. The compression you mention only consists of the wasted-bits flag, so I can't see the worry anyway. The idea behind uncompressed flac is extremely fast decoding (right?), just adding padding is not going to influence that.
Hi Martijn
First, thank you for taking the time to respond to my query. A few comments from my side.
1) Uncompressed FLAC is not something DBPowerAmp invented. They just implemented it in a nice GUI. There are other tools that support this like EAC. Except that EAC uses it through the command line. Try this in EAC and you'll get the same as in DBPowerAmp.
--disable-constant-subframes --disable-fixed-subframes --max-lpc-order=0 -V -T "ARTIST=%artist%" -T "TITLE=%title%" -T "ALBUM=%albumtitle%" -T "DATE=%year%" -T "TRACKNUMBER=%tracknr%" -T "GENRE=%genre%" -T "COMMENT=%comment%" -T "BAND=%albuminterpret%" -T "ALBUMARTIST=%albuminterpret%" -T "COMPOSER=%composer%" -T "DISCNUMBER=%cdnumber%" -T "TOTALDISCS=%totalcds%" -T "TOTALTRACKS=%numtracks%" %hascover%--picture="%coverfile%"%hascover% %source% -o %dest%
2) I also take up argument with your opinion that the FLAC project does not support this. If they did not support it, then why did they enable the command line parameters for it? Also, on XIPH.ORG you can find the references. Although it is not specifically stated, someone who knows their business can deduce exactly what it does when you disable the subframes.
3) The idea behind uncompressed FLAC is to get uncompressed LPCM with good metadata. To put that very black-and-white, to get the CD stream plus metadata. Neither WAV and AIFF support metadata (well), so uncompressed FLAC looks to offer the best of both worlds. The reason people want it is because computer audio is riddled with RF noise and ripple, so the less the CPU does, the less interference it can create. Can you really hear that? When your stereo costs more than your car, yes.
So, when I see that the FLAC is compressed, how is that not going to influence matters, as my system now needs to go through an uncompression process? Or is it in fact not decompressing despite that the OS shows that the file is compressed? Last but not least, how do you explain my experiment where I take a 16-bit file and upsample it to 24-bit (padding 8 zeros effectively) and not seeing any compression occur?
I hope I have been able to clarify the reason for my questions a bit better and I look forward to your reply.
I can only suggest you this, this or this
A very mature response for a support forum.
2) The options were added for testing purposed only. They are undocumented, and they were never meant to be used by end users directly
1) dBpowerAmp was AFAIK the first one to implement this in a GUI. Therefore I used the word 'invented'
3) Uncompressed FLAC actually loads the CPU more than regular compressed FLAC on my computer, I actually tested this sometime ago! I think this is because reading the file from the harddisk involves the CPU as well. So, with this reasoning, you're actually better off not using uncompressed FLAC at all.
Hi Martijn
Thank you for the clarification with regards to these options. What are the odds of these options becoming official?
I think DBPowerAmp is indeed the only GUI that supports it. And it is fairly 'black box' too as I had to dig around a bit before I got an idea of how it had been done.
It is likely the reading from disk into memory that would cause the spike. So, here is a question for you. The uncompression, will that take place while the file is loading into RAM or after the compressed file has been loaded into RAM completely? Just trying to understand whether it makes sense to load the file into memory first before playing starts or not.
I'm pleased, actually, that the audiophile community considers uncompressed flac an acceptable alternative to formats like wav and aiff which don't offer lossless compression. This is definitely an improvement.
We disagree there's an audio difference from disabling lossless compression, obviously, but if someone wants to do this and it encourages them to produce compatible flac files, I don't think we should push too hard against it. One can always re-compress any such files one receives.
There is definetely traction. And if you speak to Linn Audio in Scotland, they will recommend FLAC as the preferred storage and playback format. The reality is that there is a lot of theory but only a few people who really understand the stuff (and I don't pretend to be one of them). Data is scarce and whatever data is out there is usually not shared because of competitive reasons.
And you hit the nail on the head with your last comment. The beautiful thing of FLAC is that once you have it there, you can convert it to anything you want with no cost.
Shall I close this?
Yes, I'd say this is outside the scope of the FLAC project