 
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
|
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
88.97.21.18
In Reply to: RE: Bulk conversion of oversize FLAC's posted by tantra on March 16, 2018 at 09:05:40
Yes, you can use dbpoweramp. There is a bulk converter application as part of its suite of programs. This includes the ability to select various levels of FLAC compression. They call it MP3 Converter but it does a whole lot more.
None of the compression levels for FLAC will actually lose information. However many of us have found that the on the fly unzipping of FLAC files when replaying, which is the normal way it is used, can affect sound quality to a greater or lesser extent depending upon programme content and the level of compression used. My own opinion would be to use level zero (no compression but retaining FLAC tagging) unless you have storage space demands that make compression beneficial e.g. portable media players such as on a smart phone.
Follow Ups:
Par,How does decompressing a lossless codec impact sound quality unless one is using an antiquated, underpowered CPU without enough memory ?
My app decompresses and loads the entire uncompressed content into a memory buffer before starting playback so there should be no difference between lossless compressed content and non-compressed content read into and played out of the same buffer.
Edits: 03/18/18
I do not know the precise mechanism involved and only raise decompression as a sort of hypothesis.
The processor that I use a fairly recent Intel i7 with files played from JRiver 23 into an SSD memory. So I doubt that computing capability per se would be a culprit. However I am open to another explanation and if I have time in the next few days will re-check "load decoded into memory" option available in JR MC.
I would suggest reading the article in HiFi Critic which addressed the problem although offhand I cannot recall if they proffered an explanation in addition to their observations ( I should read it again myself !). This article was what started me looking at the subject a year or so back although I have been aware of a number of individuals who have mentioned their preference for the SQ of .wav files to me which I think is basically them noting the same effect.
Hi Par
From the lin k you provided:
"When we first discovered the sonic discrepancies between
WAV and FLAC formats we decided to ascertain the full
extent of this SQ loss. We did this by starting with a WAV
file, converting it to FLAC, and then back to WAV
repeatedly through five iterations. Much to our surprise we
found that the derived WAV files exhibited a highly
audible, hyperbolic decline in sound quality, as estimated
on our subjective scale, despite measuring identical by
standard null testing."
Do you believe this to be true?
The Well Tempered Computer
Do they hear the "difference" when they don't know if it is the Wave or FLAC playing? It reminds me very much of the nonsense, pseudo-scientific article that TAS published several years ago.
When they discover the center of the universe, a lot of people will be disappointed to discover they are not it. ~ Bernard Bailey
It are the same guys.
The Well Tempered Computer
The only way for that to be true is either faulty software or introducing a lossy process in the mix.That is like saying I exchanged 4 quarters for a buck and back 4 times and now I have less $$$.
Placebo effects are most likely in play here.
Edits: 03/19/18 03/19/18
Im afraid their "subjective scale" is flawed
The Well Tempered Computer
"Do you believe this to be true?"
I cannot say as I have not performed the experiment. However I do believe it to be plausible.
I don't see how it is plausible. You can convert back and forth between WAV and FLAC as many times as you like and each generation of files will be identical. It would be the same if they had simply copied the files.
It's one thing to postulate whether playing back WAV files sounds different than FLAC files because you're avoiding the little bit of processing needed to decompress FLAC on the fly. It's another thing entirely to claim that different identical copies sound different, and that sound quality gets worse in successive generations of copies.
It's another thing entirely to claim that different identical copies sound different, and that sound quality gets worse in successive generations of copies.
True but your point strikes me as another thing entirely to what the authors are claiming. Their suggestion is that successive wav> flac> wav conversions create files that are NOT identical due to issues with the flac format. They further argue that, though the differences seem negligible, they matter.
Whether they're right is also another thing entirely but it's how I read the text. I stand to be corrected.
Though I admit to being perplexed by some aspects of the experiments' design (esp the claim that image height correlates with sound quality - it strikes me as a circular argument), I don't think the paper can be dismissed simply with a wave of the hand.
Dave
I just took a high rez 2L download (24 bit/352.8K, 412.66MB) WAV file and used dBPowerAmp to convert it to FLAC using the highest compression setting of 8. I then converted the FLAC file to WAV and repeated the process multiple times to create multiple generations of transcodes.I then compared the raw binary file data of the intermittent WAV files in Linux. The only difference is between the 1st WAV file (and the all of the rest) due to some meta data loss on the first FLAC conversion. All of the subsequent WAV files are BIT-IDENTICAL (including the meta data portions).
Since all of the subsequent WAV files are BIT-IDENTICAL, this suggests that their hypothesis that there is compounding generational copy/translation loss/degradation with each FLAC conversion is totally unfounded. Each generation of the FLAC transcodes produces the identical WAV file.
I am now looking for a program that will just compare the audio portions between the first and nth WAV files to guarantee the audio content remained bit-identical on the initial conversion.
Edits: 03/20/18
I used ffmpeg to calculate the MD5SUM for the audio data in the original and subsequent WAV files. They are identical.The MD5SUM's are also identical to the generational FLAC files (all 9 generations).
Edits: 03/20/18 03/21/18
True but your point strikes me as another thing entirely to what the authors are claiming. Their suggestion is that successive wav> flac> wav conversions create files that are NOT identical due to issues with the flac format. They further argue that, though the differences seem negligible, they matter.
That's not how I read it. Before they got into investigating metadata, they started with a simple repeated sequence of 5 FLAC to WAV conversions using the same dBpoweramp software and settings, and they say in part 1 that these are bit perfect copies, as they should be.
One other note. When dBpoweramp rips audio content, the CRC that determines if the rip is bitperfect or not is based on the audio data, not the meta data. The meta data is just optional window dressing.If the software is working properly, the only possible difference I see could be disk fragmentation if they are using a fragmented full disk (read: operator error). Defragging the disk would address that issue so the files are stored in a contiguous fashion on disk.
Edits: 03/19/18
I will try to cover two postings with a single one of my own.
Dave K's argument regarding identical data is correct but is not really exactly germane to my answer to Roseval's question. As a reminder, Roseval asked if I believed the reports findings to be "true". I deliberately avoided giving an affirmative answer. If I had then Dave K's counter argument fits the discussion well.
However the quotation cited actually concerns whether or not some individuals heard a difference between two formats even though the data held therein is identical. That seems quite plausible (it may or may not be true). It is plausible because they say that their finding is subjective and not objective. They acknowledge that the data is identical. There may be reasons why they heard differences but these may not be related to the data per se. One may speculate what these reasons may be.
Just to correct your reading of the report they do NOT claim that the transformed files are not identical. Rather the opposite as they say the differences are heard " despite measuring identical by
standard null testing."
they do NOT claim that the transformed files are not identical
My reading is that they do though, obviously, they don't suggest that the music data are changed. Such would be absurd.
They report that the observed differences in "image height" which correlate with SQ also correlate with changes to what they term (pt 2, p 1) Metadata-Associated Art (MDA). (They call it MDA to distinguish what gets embedded in the file from the source image.)
Metadata are surely as much part of a file as, say, headers or CRCs. IOW, change the metadata and you change the file.
HTH
Dave
"... Metadata are surely as much part of a file as, say, headers or CRCs. IOW, change the metadata and you change the file. ..."
Adding, removing, and adding meta data ONLY changes the meta data, not the audio data. If it did change the audio content, the software used is faulty.
Adding, removing, and adding meta data ONLY changes the meta data, not the audio data.I know. I just said much the same thing.
If it did change the audio content, the software used is faulty.
Can you tell me where in the paper the authors suggest that audio data are altered?
What they claim is a bit more subtle than that. They argue that storing images in flac-format metadata degrades audio reproduction and that that degradation is compounded by the repeated flac > wav > flac conversions that inevitably occur in the data trail from studio to end user.
You can accept that, reject it or, like me, remain indifferent absent better experiments but that's what they say though you do need to read all of the paper to be clear.
In passing, the experimental design did address "placebo effects" with, for audio, unusual rigour. Audiophiles typically use "placebo" as a term of abuse when they don't understand something and don't much want to. I don't think it's a pertinent notion here.
IMHO, key faults with the study include:
* Using "height measurements" as a proxy for SQ on the basis that they correlate within a very limited sample range (as I read it, ten seconds from one recording).
* Using JRMC as the only playback program and a sub-optimal (in audio terms) desktop PC as the music "server". The article dates from (I think) 2016. By then, JRMC on a vanilla WinTel box was hopelessly obsolete.
++++
Disclaimer: the paper interested me because, like PAR, I readily hear SQ differences between flac- and wav-format data. I use a DIY'd cMP2-based Network Audio Adapter. I have for years routinely deleted all but a minimum of text-only tags from audio files purely on the basis that less is typically more in audio and that doing so is free and trivial to do.Others seem to like bloatware: si tibi placet, est fine by mihi.
D
Edits: 03/20/18 03/20/18 03/20/18
"... Can you tell me where in the paper the authors suggest that audio data are altered? ..."They implied it by saying the sound changed through generational copy loss and lossless format changes.
"... What they claim is a bit more subtle than that. They argue that storing images in flac-format metadata degrades audio reproduction and that that degradation is compounded by the repeated flac > wav > flac conversions that inevitably occur in the data trail from studio to end user. ..."
Absolute BS. Bit-perfect copies do not suffer from Xerox generational photo-copy-like degradation. They are conflating two different technologies (lossy and non-lossy copies). The audio content remains identical, as it should unless the software, hardware or operator's actions used is faulty.
If they are using a marginal system with insufficient hardware the extra resources required to handle the meta-data "may" make a difference, but doubtful it will impact the sound quality in a way OTHER than intermittent glitches and stutters due to increased latencies caused by additional processing, longer or more frequent latencies and swap disk activity (i.e. won't sound like lost resolution). Remember the days when you would get a bad rip on Windows if any other software was running while trying to rip a disc ? Windows NT was Microsoft's first attempt at preemptive multitasking and the designer was a former VMS guy who reused some of VMS's problematic designs. Another example, I just put JRMC 23/64-bit on an old laptop that could not seamlessly handle the 32-bit version. It now plays just fine with the optimized 64-bit implementation where it was intermittent with the 32-bit version (read: that laptop was marginal hardware).
"... Audiophiles typically use "placebo" as a term of abuse when they don't understand something and don't much want to. ..."
I have written software for over 30 years (from embedded devices to super computers, including compression, cryptography, storage, comm protocols, HDTVs, VOD, DVRs and DLNA down to the hardware level shifting bits out of UARTs) and have a fair understanding of what goes on inside of a computer. If you live in the USA, you have a good chance of having owned/used some of my software. If you can't guarantee bit-perfect consistency, your design and/or implementation is broken or lossy by design.
The testers should have used DLP Latency Checker (or similar) on their PC to first see if their PC was suitable for audio playback and second to see if the interrupt latencies changed between playing the wav and the flac versions. This would give an indication if their hardware was suitable, marginal or not suitable for audio playback.
Edits: 03/20/18 03/20/18 03/20/18
I re-skimmed their white paper. I could NOT find any place in the article where they checked the audio contents of the various files to see if they changed. They used a measuring tape (what?) and an oscilloscope. They appear to have missed the obvious most pertinent metric. Are the bits in the various copies the same or have they changed and how? That should have been the first question to ask and answer.They did not appear to verify the lossless copies. Kind of a HUGE oversight in their testing process before skipping to a conclusion. So much for following a valid protocol to prove/disprove a hypothesis.
Blonde Driver: My car stopped, my engine must be broken.
Mechanic: Is the gas tank empty ?"... FLAC can handle any PCM bit resolution from 4 to 32 bits per sample, any sampling rate from 1 Hz to 655,350 Hz in 1 Hz increments, and any number of channels from 1 to 8. ... FLAC uses CRC checksums for identifying corrupted frames when used in a streaming protocol, and also has a complete MD5 hash of the raw PCM audio stored in its metadata header. ..."
Edits: 03/20/18 03/20/18 03/20/18 03/20/18 03/20/18 03/20/18
I re-skimmed their white paper.
And again, it seems, missed the point. I'm not going to waste any more time discussing it with people who, despite illustrious careers, don't bother to read it properly. It is indeed (IMHO) flawed but, emphatically, not for the banal reasons you and others suggest.
Had you read it with even a modicum of care, you'd have eschewed fatuous comments such as "They implied it by saying the sound changed through generational copy loss and lossless format changes".
That sort of sloppiness I can do nothing about.
D
Sloppiness, I pointed out their sloppiness and faux testing methods that would NOT stand up under any scientific scrutiny.The simple software tests that I conducted yesterday (THAT CAN BE RELIABLY REPEATED BY ANYONE) proved they are FOS. They did NOT include those tests in their pseudo white paper. Bit identical files are indistinguishable from each other, period.
If bit identical files were different, computers would produce random results and simply would not work. Let that sink in for a moment. Imagine the look on Microsoft's face when they recompile a bit perfect copy of the MS Word source code and it produces the MathCAD binary. =)
Edits: 03/21/18 03/21/18 03/21/18 03/21/18
I don't think you understood the paper. They absolutely do say that the sound changes through generational loss by simply converting back and forth between FLAC and WAV. They later tested without metadata, and found the degradation via generational loss was still there albeit much reduced. And then went on to attribute most of that change to embedded album art.
But the whole point of these two papers and their earlier TAS report is that sound quality continues to degrade with repeated conversions between FLAC and WAV even if the files are identical.
"... They absolutely do say that the sound changes through generational loss by simply converting back and forth between FLAC and WAV. ..."That statement is a repackaging of the same statement made about generational copies of CDs years ago when no one would verify their copies were bit perfect.
"... sound quality continues to degrade with repeated conversions between FLAC and WAV even if the files are identical. ..."
Absolute BS. The only thing going on there is user error, disk fragmentation and falsely applied assumptions.
Edits: 03/21/18
But the whole point of these two papers and their earlier TAS report is that sound quality continues to degrade with repeated conversions between FLAC and WAV even if the files are identical.
I haven't read the earlier papers so can't comment on them but, wrt the papers to hand, yes, I know that. My point, which you take out of context, was answering the suggestion that the authors didn't understand the difference between lossy and lossless data.
I never said I agreed with paper's conclusions - four of my five posts above critcise it - but I did suggest that people should read it properly before commenting on it. TBH, it hadn't occured to me that that might be seen as a toxic notion.
D
The headers and metadata aren't changing from generation to generation though. So even if the presence of metadata in the file (images or other) has an impact on sound quality, there is no generational loss.
I am also a dBpoweramp user, and to prove to myself that it's not doing something strange, I took a random FLAC file from my library, with metadata, and renamed it f1.flac. Using dBpoweramp music converter, I converted f1.flac to f1.wav. Again using dBpoweramp music converter, I converted f1.wav to f2.flac. And then f2.flac -> f2.wav, and so on until I had 5 of each.
There was a difference between f1.flac and f2.flac. I dug into it and found that I had lost replaygain metadata through the conversion, because it wasn't supported in WAV. But everything else was the same. But f1.wav through f5.wav were identical, as were f2.flac through f5.flac. Just to be clear, it wasn't just the audio data that were identical. The files were identical.
So even if the presence of metadata in the file (images or other) has an impact on sound quality, there is no generational loss.
I got the same result though, as noted, I don't store images in the files.
Before loading an album onto my "server", I use Tag&Rename to clear its metadata and derive new tags from the file names. Then I convert to flac for backup. Happily but as expected, the tags survived backing up, restoring and converting back to wav following a recent drive failure.
IIRC, the TAS paper is coy on data prep procedures, surely another significant weakness in its argument. For reasons why it might matter, see Roseval's recent link (though I still dispute his blanket claim that "Memory playback removes all the differences due to processing").
D
My oldest car only has CD playback capability, so I've used dbPoweramp to convert 24 bit stuff to 44/16 for burning to CD-Rs.
| FAQ |
Post a Message! |
Forgot Password? |
|
||||||||||||||
|
||||||||||||||
This post is made possible by the generous support of people like you and our sponsors:
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2025, Audio Asylum, all rights reserved ]
