|
Post by qdtjni on Aug 15, 2015 13:42:08 GMT -5
IIRC, they claimed that FLAC with compression sounded worse, which it could in a poor implementation (in a wide sense including HW). If one still is afraid of FLAC or ALAC, do yourself a favour rip them in a format that supports tags, then transcode to WAV.
At least you have the files with tags so you can use them once you realise it's useful with tags.
|
|
|
Post by Priapulus on Aug 15, 2015 13:42:36 GMT -5
If one insist on storing non compressed, at least use a format that supports tags for meta data. Absolutely. And use a tag editor to correct the information, including imbedding folder photos. Players use tags to build its database, errors and missing info can really mess up a database, causing "missing" songs.. Sincerely /b
|
|
|
Post by ludi on Aug 15, 2015 13:46:37 GMT -5
I did a quick test: I took an original WAV file, created a FLAC, then from that FLAC I created a new WAV file. Then I ran a binary compare checking the WAV files:
|
|
|
Post by qdtjni on Aug 15, 2015 13:48:33 GMT -5
I did a quick test: I took an original WAV file, created a FLAC, then from that FLAC I created a new WAV file. Then I ran a binary compare checking the WAV files: Of course they are.
|
|
|
Post by ludi on Aug 15, 2015 13:53:46 GMT -5
I did a quick test: I took an original WAV file, created a FLAC, then from that FLAC I created a new WAV file. Then I ran a binary compare checking the WAV files: Of course they are. Trust, but verify
|
|
|
Post by qdtjni on Aug 15, 2015 14:00:24 GMT -5
Of course they are. Trust, but verify Very good!
|
|
|
Post by monkumonku on Aug 15, 2015 15:41:03 GMT -5
I did a quick test: I took an original WAV file, created a FLAC, then from that FLAC I created a new WAV file. Then I ran a binary compare checking the WAV files: Of course they are. Ah, but even so, in the world of audio marketing that means absolutely nothing. The relevant question thing to ask is, "what do you mean by 'identical'?" Or what is the meaning of "are"... Audioquest would tell you some cables are more identical than others.
|
|
|
Post by garym on Aug 15, 2015 21:52:21 GMT -5
Some (including 'The Absolute Sound" magazine) claim that the compression/decompression sequence damages the sound. The majority of critical listeners (including the majority on this Lounge), claim that any such artifacts are not measurable, and thus, inaudible. There is (as of yet) no definitive answer on that question. Actually, there is a definitive answer. Compress a WAV file to FLAC, convert it back to WAV (several audio conversion utilities can do this), save with a new name. then compare the two files with a binary file comparison tool. such as FC (a command line program included with Windows). There will be no differences. If someone contends he can hear a difference between two identical files, it is either his imagination or something is wrong with his player (it is flubbing the decompression). EDIT: I see someone beat me to it!
|
|
|
Post by ludi on Aug 16, 2015 4:08:31 GMT -5
Some (including 'The Absolute Sound" magazine) claim that the compression/decompression sequence damages the sound. The majority of critical listeners (including the majority on this Lounge), claim that any such artifacts are not measurable, and thus, inaudible. There is (as of yet) no definitive answer on that question. Actually, there is a definitive answer. Compress a WAV file to FLAC, convert it back to WAV (several audio conversion utilities can do this), save with a new name. then compare the two files with a binary file comparison tool. such as FC (a command line program included with Windows). There will be no differences. If someone contends he can hear a difference between two identical files, it is either his imagination or something is wrong with his player (it is flubbing the decompression). EDIT: I see someone beat me to it! Actually I used HxD to do the compare.
|
|
|
Post by Boomzilla on Aug 16, 2015 6:24:30 GMT -5
Some (including 'The Absolute Sound" magazine) claim that the compression/decompression sequence damages the sound. The majority of critical listeners (including the majority on this Lounge), claim that any such artifacts are not measurable, and thus, inaudible. There is (as of yet) no definitive answer on that question. Actually, there is a definitive answer. Compress a WAV file to FLAC, convert it back to WAV (several audio conversion utilities can do this), save with a new name. then compare the two files with a binary file comparison tool. such as FC (a command line program included with Windows). There will be no differences. If someone contends he can hear a difference between two identical files, it is either his imagination or something is wrong with his player (it is flubbing the decompression). EDIT: I see someone beat me to it! Your method is flawed. The bits CAN be the same, but if the jitter is increased by the dual conversions, then it's possible that the two can sound differently. In fact, the difference (if there is one) may be sufficient to trigger the playback system's error correction more frequently than the original. In short, there's more to a "bit perfect copy" than just bits. Now, that said, it's also possible (likely?) that the TAS folks are just up to more of their looniness, and that what sells magazines has no connection to reality. My inclination, personally, is to dismiss the TAS allegations, BUT - My WAV files DO sound both differently (and, to my ears better) than did the same bits in ALE format. The comparison wasn't scientific (no matched levels), so treat this with a grain of salt. I also tried FLAC & couldn't tell any difference from WAV, but again, not a rigorous test. Ultimately, I"m happy with WAV, so the question is academic. YMMV
|
|
|
Post by qdtjni on Aug 16, 2015 6:58:11 GMT -5
There can be absolutely no jitter introduced in a simple fomat conversion. The conversion can cause a difference in sound though, but then it is not due to the format conversion but rather to poor implementation such as too small buffers, too little CPU, etc or due to possible introduction of electrical interference.
What error correction are you referring to?
As for your experience of WAV vs ALE, if I understood you correctly you compared ALE in iTunes with WAV in jRiver. Did I get that right?
|
|
|
Post by garym on Aug 16, 2015 9:23:11 GMT -5
Your method is flawed. The bits CAN be the same, but if the jitter is increased by the dual conversions, then it's possible that the two can sound differently. If the first conversion (WAV to FLAC) introduced any errors then the two files would not be the same (unless, miraculously, the decompression happened to introduce errors that exactly corrected the compression errors!). As KeithL mentioned in an earlier post, if the hardware is not up to snuff, or the player software is bungling the conversion, then you might hear differences. But if you're using the same machine and software to play your music as you used to create and uncompress the FLAC and WAV you tested, you can rule that out. Jitter is a timing error caused by an inconsistent clock, especially the clock in the DAC. Unless your DAC is unbuffered and is relying on the PC's clock for its timing, errors from the PC or the player during decompression would be eliminated by the buffers in the DAC prior to conversion to analog.
|
|
|
Post by Boomzilla on Aug 16, 2015 9:50:52 GMT -5
OK - Not to belabor the point but...
When you convert from one file to another, the pieces of the file are scattered to different physical locations on the hard drive's magnetic platter. So the drive heads have to seek differently to find the new file. As the drive itself wears, its indexing becomes less precise. So not only is the head activity different, but also the drive may have to reread portions of the file repeatedly to confirm the data. Yes, the drive has a buffer to ensure that the data appears continuous, but who's to say that you're not having delays while the buffer refreshes from the platter?
So with the read buffer and the write buffer, yes, the file would appear identical, but in dynamic reads, perhaps less.
Additionally, with ANY codec, the CPU must manipulate the data to provide it in the desired output format. The more manipulation the CPU must do, such as separating cover art from music data or interpolating missing data from lossy codecs, the less contiguous will be the output data.
Now, admittedly, the above are absolute speculation on my part. The fact that even the most CPU-intensive codecs appear to stream seamlessly for audio data would argue against the significance of any of the above. And yes, jitter IS primarily a communication error - not inherent in the source stream.
So the bottom line is: I don't really know. And it's not much of an issue for me since I run uncompressed files anyway.
Cheers - Boom
|
|
|
Post by qdtjni on Aug 16, 2015 10:18:02 GMT -5
OK - Not to belabor the point but... When you convert from one file to another, the pieces of the file are scattered to different physical locations on the hard drive's magnetic platter. So the drive heads have to seek differently to find the new file. As the drive itself wears, its indexing becomes less precise. So not only is the head activity different, but also the drive may have to reread portions of the file repeatedly to confirm the data. Yes, the drive has a buffer to ensure that the data appears continuous, but who's to say that you're not having delays while the buffer refreshes from the platter? So with the read buffer and the write buffer, yes, the file would appear identical, but in dynamic reads, perhaps less. Additionally, with ANY codec, the CPU must manipulate the data to provide it in the desired output format. The more manipulation the CPU must do, such as separating cover art from music data or interpolating missing data from lossy codecs, the less contiguous will be the output data. Now, admittedly, the above are absolute speculation on my part. The fact that even the most CPU-intensive codecs appear to stream seamlessly for audio data would argue against the significance of any of the above. And yes, jitter IS primarily a communication error - not inherent in the source stream. Sorry Boom but that is just simply not how it works.
|
|
|
Post by Boomzilla on Aug 16, 2015 10:48:19 GMT -5
OK - I believe you. I was basically looking for any logical explanation for why a FLAC file might sound differently from a WAV. Apparently, there isn't one - and my initial speculation that TAS is interested in selling magazines rather than scientific audio information is the correct one.
Thanks - Boom
|
|
|
Post by garbulky on Aug 16, 2015 12:27:11 GMT -5
Well my guess is that I assume the decoded buffer is stored in RAM memory. So the platter thing wouldn't affect it too bad.
|
|
|
Post by taxman2 on Aug 17, 2015 6:36:56 GMT -5
I still think resampling 16b 44.1kHz to 32b 352.8kHZ sounds better to my ears. Like the highs are clearer and detailed. But off course I could be imagine it.
|
|
|
Post by ludi on Aug 17, 2015 9:21:41 GMT -5
I still think resampling 16b 44.1kHz to 32b 352.8kHZ sounds better to my ears. Like the highs are clearer and detailed. But off course I could be imagine it. ... but then you don't have identical binary data
|
|
|
Post by taxman2 on Aug 19, 2015 7:35:10 GMT -5
For me uncompressed flac files sound better. There is a subtle difference, but definitely do sound better.
|
|
|
Post by GreenKiwi on Aug 19, 2015 9:32:16 GMT -5
OK - I believe you. I was basically looking for any logical explanation for why a FLAC file might sound differently from a WAV. Apparently, there isn't one - and my initial speculation that TAS is interested in selling magazines rather than scientific audio information is the correct one. Thanks - Boom That would certainly be my speculation. That being said, I could see cases where one could think that things sound different. For example, if you aren't paying attention, you might have replay gain applied to the FLAC playback and not the WAV. Or the software could be faulty. The one thing that I do feel should be out there is that there is just SO SO SO much procession power and memory out there that I find it hard to put validity to claims that the decompressing causes problems. Hell, my iPhone 4 could play back FLAC files w/o any problems. One more thing, there are programs that read the whole file into memory. I am not totally sure how those work, but I am guessing that at least one of them will have the whole file loaded in and stored in PCM data (i.e. WAV). This is one area that I would absolutely love to see a controlled ABX/Double blind test...
|
|