SACD to FLAC Volume Conversion Issues and Fixes

[SeeMoreDigital]

Yeah, but I don't listen to music that way typically. I have streaming options that center around .flac. For years I've just been maintaining a folder of .iso files I rarely do anything with. It just doesn't fit in with my scheme, and I'm realizing it makes no sense to keep maintaining a folder of files I do nothing with.

Please explain your 'scheme'? How do you access and play your audio files?

 

[ArmyOfQuad]

I'd rather not. I know you mean well, and I appreciate your desire to jump in and help. But I rather dislike when I post a question, and the response tries to get steered towards "well, what you really want to do is..." followed by what I don't want to do.

I really don't need to defend my scheme here - I simply wanted to see if anyone else had pursued and come up with a similar type of workflow to what I'm looking to do.

 

[mandrix]

I don't personally know how to automate your process, AoQ, but with Foobar and some programming skills it certainly seems possible.
Good luck.

 

[Quadlover]

ISO2DVD seems to be working fine for me. It is freeware. https://www.sonore.us/iso2dsd.html

 

[SeeMoreDigital]

ISO2DVD seems to be working fine for me. It is freeware. https://www.sonore.us/iso2dsd.html

I've already mentioned ISO2DSD here: https://www.quadraphonicquad.com/fo...onversion-issues-and-fixes.37269/#post-840384

However, if your're a MAC (or Linux) user Sonore also offer DSD2FLAC. Which also requires Java.

 

[ArmyOfQuad]

iso2dsd is exactly that. Iso to DSD. Which is only 1 step of the ISO to flac process. iso2dsd is basically a gui that utilizes sacd_extract.exe, which is what I'm using for my iso to dsd portion of my process I'm building.

I have a somewhat working process that then flattens the folders (sacd_extract.exe seems to have this folder struction creation hard coded with messes with things, so a script was built to flatten that down to the parent folders I created for stereo and multi), then a script that uses ffmpeg and sox to scan levels and come up with a recommended gain without having to do a full .wav conversion, then a script that uses ffmpeg to convert the .dsf files to flac with applied gain.

Problem is using ffmpeg to convert .dsf track by track results in the dreaded track transition pops issue - one of many reasons for why I now have decided I despise SACD and feel the world would've been a better place if it was never unleashed on us!

So - taking a step back, my angle is now to get full album dsf files with .cue, do a full album dsf to wav conversion with gain, then a wav to flac conversion with use of the .cue to split.

I'm finding that there doesn't seem to be a way to force sacd_extract.exe to do a full album extraction, but there seems to be an option to concatenate the files into a full album file. So now I'm working on that step.

Not sure why all the tools that exist seem to try so hard to drive away from full album extraction. Foobar can do it, but only by a convoluted process to "fool" it - you uninstall the SACD add-in to foobar, drag in the SACD iso which makes a single item playlist, reinstall the SACD add-in, and now you're in a state where your .iso is in a playlist as a single item, and foobar can play it - which means you can convert it to a full album file. Problem is, it seems to only do the stereo if it's hybrid. Not sure if I ever came up with a workaround for that, I abandoned that workaround once I found foobar can get around the pops if you set it to do one file at a time.

 

[ssully]

The fear of audibly wasting bits if your PCM files peak at -6dB -- which all of this seems to be based on -- is mainly audio nervosa , especially if the source is from analog tape, and there's an argument that peaking a few dB down from 0dBFS is good insurance against intersample overs at playback(....which are also probably inaudible, unless there's a serious mass of them)

NB the current default output level for foo_sacd_input (v1.5.11) is +6dB. A 6dB boost. That absolutely WILL result in overloads from some SACDs*, visible in the waveforms.

To maximize the peak level without such overloads, I check the 'Log Overloads' option in foo_input_sacd and monitorthe process in the foobar Console, which shows such errors in real time (the log is also saved as a text file if you don't feel like monitoring). Start at the default (+6) and check for overloads. If they appear, try +5. Rinse and repeat until no overloads. Then rip the disc at that setting (checking the log file for overloads just in case).

Tedious at first , when I had to convert my few dozen existing SACDs, but now my rate of buying converting SACDs is like once or twice a year, so not a big deal.

(*MJ's Thriller has a few overloads even when ripped +0dB ...but they are inaudible. They are errors printed into the SACD.)

 

[mister_eff]

replaygain keeps saying the levels are in the range I want already, but all conversions give me .flac files at -5. Sure, I can manually boost, but I need to automate. Yet to find a way to get a reliable read and setting set. It seems the only way is to convert, check each file, manually set - this is way too many steps and way too time consuming. We can land a man on the moon, but we can't read an accurate level of an audio file and set a gain automatically to rip a decent flac?

To maximize the peak level without overload, I check the 'Log Overloads' option in foo_input_sacd and monitorthe process in the foobar Console, which shows such errors in real time (the log is also saved as a text file if you don't feel like monitoring). Start at the default (+6) and check for overloads. If they appear, try +5. Rinse and repeat until no overloads. Then rip the disc at that setting (checking the log file for overloads just in case).

This is literally what I do when I convert my SACDs to FLAC using foobar (manually boost, check levels, re-convert as needed). It is time consuming but I am obsessive compulsive and try to maintain the 0.9+ peak per album, so it works for me.

(I also understand that it's audio nervosa--a term I've never heard before but makes sense--but I just like doing it anyway)

 

[mister_eff]

Please explain your 'scheme'? How do you access and play your audio files?

I'm not the OP, but I listen to SACD rips on my AVR that does room correction, which I believe is done in the PCM domain, so any DSD file would just get converted to PCM by the AVR. Converting my SACD rips manually gives me control over the conversion process. I also find that tagging is more robust/easier to deal with with FLACs than DSD files, and I can level match my SACD rips with Replaygain so I don't have to adjust the volume as much when I alternate between SACD rips and regular PCM files.

 

[ssully]

NB to shorten the overload-avoidance process somewhat I start with just the track I predict will be the loudest and go by that basis. But I still check the log after the whole album is converted.

 

[ArmyOfQuad]

Going back to my education, setting levels to maximize bit use was a concept, but I don't recall there ever being a rule of thumb for a target. Just that in digital it was a hard limit, never go over 0, whereas analog was different, of course. So when recording you wanted to make sure you leave room to not hit 0. But, when maximizing already recorded material, it was suggested not to go right to 0, but there was never any hard rule or recommendation suggested to us as to how much headroom. I typically left .5, since the only solid teaching I had was don't hit zero, don't leave too much headroom to maximize bit use, and don't go right up to 0.

Which means - it's probably not a bad idea to revisit this rule. So I asked what a recommended headroom would be. AI's response:

When creating digital audio files, a good practice is to leave 6 dB of headroom when setting levels. This means keeping your peak levels around -6 dBFS (decibels Full Scale) in your digital audio workstation (DAW) or recording software. Here's why and some context:

• Avoid Clipping: Digital systems have a hard limit at 0 dBFS, beyond which audio clips and distorts unpleasantly. Leaving 6 dB of headroom ensures you stay safely below this ceiling, even if unexpected peaks occur during recording or mixing.
• Mixing Flexibility: During post-production, additional processing (like EQ, compression, or effects) can increase the signal level. Starting with -6 dBFS gives you room to work without hitting 0 dBFS prematurely.
• Industry Standards: While there's no universal rule, -6 dB is a widely accepted guideline for raw recordings or pre-mastered mixes. For final masters, some aim closer to -1 dBFS to maximize loudness, but this depends on the delivery format (e.g., streaming platforms often normalize anyway).

For practical application:

• Set your input levels so the loudest parts hit around -12 to -6 dBFS during recording.
• In mixing, aim for peaks between -6 and -3 dBFS before mastering.

This approach balances signal quality and flexibility, avoiding the risks of pushing levels too close to 0 dBFS. If you’re targeting a specific loudness standard (like -14 LUFS for streaming), that’s a separate consideration applied during mastering, not initial level setting.


Did I really need to use AI for this? No - this is a new kick I"m on just to learn about it. On the one hand, it's great at being able to quickly consult with multiple websites and give a good summary. ON the other, I'm also learning all the ways it goes off the rails.

So there it is, -6 is a widely accepted guideline.


However - rip a CD, and will you find that? Heck no! And so already my flac library of CD rips is not leaving 6dB of headroom, and that's never caused me problems for the decades of CD listening and file ripping. So perhaps this -6 rule is more for industry purpose, not end user delivery.


So where am I with all this? I dunno, still thinking it out as a type.

I guess my takeaway is:
-6dB isn't an awful thing
but it also isn't an industry practice for CD delivery
Even if you take that, there's still the desire for consistency in SACD ripping, which means some sort of leveling process will still be needed

I've been putting in a 1dB headroom buffer in my process I'm building - maybe I'll split the difference and back it off to 3.

 

[ssully]

Going back to my education, setting levels to maximize bit use was a concept, but I don't recall there ever being a rule of thumb for a target. Just that in digital it was a hard limit, never go over 0, whereas analog was different, of course. So when recording you wanted to make sure you leave room to not hit 0. But, when maximizing already recorded material, it was suggested not to go right to 0, but there was never any hard rule or recommendation suggested to us as to how much headroom. I typically left .5, since the only solid teaching I had was don't hit zero, don't leave too much headroom to maximize bit use, and don't go right up to 0.

I don't know what teaching that was, but as you found from AI, -3dB is a reasonable target *if* you are concerned with intersample overs, and for DSD-->PCM, a 6dB differential is the way SACDs were designed -- again to avoid overloads.

We saw in early days of CDs, there was no obsession with 0dBFS peaks. Those were also the days when an album mastering typically only had a single highest peak, rather than a f*ck ton of compressed/limited peaks at or near 0dbFS.

Which means - it's probably not a bad idea to revisit this rule. So I asked what a recommended headroom would be. AI's response:

When creating digital audio files, a good practice is to leave 6 dB of headroom when setting levels. This means keeping your peak levels around -6 dBFS (decibels Full Scale) in your digital audio workstation (DAW) or recording software. Here's why and some context:

• Avoid Clipping: Digital systems have a hard limit at 0 dBFS, beyond which audio clips and distorts unpleasantly. Leaving 6 dB of headroom ensures you stay safely below this ceiling, even if unexpected peaks occur during recording or mixing.
• Mixing Flexibility: During post-production, additional processing (like EQ, compression, or effects) can increase the signal level. Starting with -6 dBFS gives you room to work without hitting 0 dBFS prematurely.
• Industry Standards: While there's no universal rule, -6 dB is a widely accepted guideline for raw recordings or pre-mastered mixes. For final masters, some aim closer to -1 dBFS to maximize loudness, but this depends on the delivery format (e.g., streaming platforms often normalize anyway).

For practical application:

• Set your input levels so the loudest parts hit around -12 to -6 dBFS during recording.
• In mixing, aim for peaks between -6 and -3 dBFS before mastering.

This approach balances signal quality and flexibility, avoiding the risks of pushing levels too close to 0 dBFS. If you’re targeting a specific loudness standard (like -14 LUFS for streaming), that’s a separate consideration applied during mastering, not initial level setting.


Did I really need to use AI for this? No - this is a new kick I"m on just to learn about it. On the one hand, it's great at being able to quickly consult with multiple websites and give a good summary. ON the other, I'm also learning all the ways it goes off the rails.

So there it is, -6 is a widely accepted guideline.


However - rip a CD, and will you find that? Heck no! And so already my flac library of CD rips is not leaving 6dB of headroom, and that's never caused me problems for the decades of CD listening and file ripping. So perhaps this -6 rule is more for industry purpose, not end user delivery.

You're forgetting the part here:

• Industry Standards: While there's no universal rule, -6 dB is a widely accepted guideline for raw recordings or pre-mastered mixes. For final masters, some aim closer to -1 dBFS to maximize loudness, but this depends on the delivery format (e.g., streaming platforms often normalize anyway).

But AI is wrong, it's not just 'some' --- obviously, most popular music CDs for a long time now have aimed for -1 or *higher* as the peak level.

So where am I with all this? I dunno, still thinking it out as a type.

I guess my takeaway is:
-6dB isn't an awful thing
but it also isn't an industry practice for CD delivery

Your AI didn't say it was. -6dB peak on CDs hasn't been an industry standard since...ever?. But it's true that peak levels on first generation CDs didn't obsess on 'max' the way modern CDs do.

Even if you take that, there's still the desire for consistency in SACD ripping, which means some sort of leveling process will still be needed

I've been putting in a 1dB headroom buffer in my process I'm building - maybe I'll split the difference and back it off to 3.

It would be hard to go wrong with that.

 

[ssully]

But your tool still needs to calculate what overall level boost gets you to a peak of -3 dBFS

 

[ArmyOfQuad]

But your tool still needs to calculate what overall level boost gets you to a peak of -3 dBFS

That's been handled (although I haven't changed it from -1 to -3 yet - the highlighted part of final masters going to -1 has me leaning towards not being that far off with my first value)

Here's the python script that handles the multichannel portion - been splitting these processes out to separate scripts for the multi and stereo, since the final tool may need to call on stereo only discs, or I might have a disc that I want to skip the stereo portion of when converting.

Not sure if this is of use to anyone - but thought it may be fun to share a sample of the types of things I have AI writing for me. Will share more when I have a finished process.



import os
import subprocess
import re
import sys

# Configuration
base_output = r"M:\Staging\SACDout"
ffmpeg_path = r"C:\Program Files\FFmpeg\bin\ffmpeg.exe"
sox_path = r"C:\Program Files (x86)\sox-14-4-2\sox.exe"
multi_dir = os.path.join(base_output, "Multichannel")

# Check directory
if not os.path.isdir(multi_dir):
print(f"Error: Multichannel directory not found in {base_output}")
sys.exit(1)

def get_peak_level(dsf_file):
cmd = f'"{ffmpeg_path}" -i "{dsf_file}" -f f32le -ar 88200 - | "{sox_path}" -t raw -r 88200 -e float -b 32 - -n stats'
print(f"Running: {cmd}")
result = subprocess.run(cmd, shell=True, capture_output=True, text=True)
if result.returncode != 0:
print(f"Failed for {dsf_file}: {result.stderr}")
return None
output = result.stderr
# Parse single max peak for all channels
peak_match = re.search(r"Pk lev dB\s+(-?\d+\.\d+)", output)
if peak_match:
return [float(peak_match.group(1))]
print(f"No peak levels found for {dsf_file}: {output}")
return None

def analyze_peaks_multichannel():
print(f"\nAnalyzing Multichannel files in {multi_dir}:")
all_peaks = []
for file in os.listdir(multi_dir):
if file.endswith(".dsf"):
dsf_path = os.path.join(multi_dir, file)
peaks = get_peak_level(dsf_path)
if peaks:
print(f" {file}: Max Peak {peaks[0]} dBFS")
all_peaks.extend(peaks)
if not all_peaks:
print("No valid peaks found in Multichannel directory.")
return 0.0
max_peak = max(all_peaks)
gain = round(-1 - max_peak, 1) # Target -1 dBFS with 1 dB buffer
print(f"Multichannel Max Peak: {max_peak} dBFS, Suggested Gain: {gain} dB")
return gain

if __name__ == "__main__":
gain = analyze_peaks_multichannel()
print(f"\nMultichannel peak analysis complete! Returning gain: {gain}")

 

[ssully]

That's been handled (although I haven't changed it from -1 to -3 yet - the highlighted part of final masters going to -1 has me leaning towards not being that far off with my first value)

Here's the python script that handles the multichannel portion - been splitting these processes out to separate scripts for the multi and stereo, since the final tool may need to call on stereo only discs, or I might have a disc that I want to skip the stereo portion of when converting.

Not sure if this is of use to anyone - but thought it may be fun to share a sample of the types of things I have AI writing for me. Will share more when I have a finished process.

Can I ask what literal query you fed to AI to generate this?

 

[ArmyOfQuad]

This was the outcome of a conversation really. Way too long to give you a literal query.

I kinda accidentally stumbled into this project. At first I thought I'd come up with the best workflow and ask AI how I can automate it.

For years now I've found that search engines respond to questions, and so when I have a question, my starting point is to ask the search engine that. So that's how I've been treating AI, ask it a question, and see where that takes me.

And when it takes me to python code, then I can tell it what it did wrong, or copy paste the incorrect output, and it gives me a corrected version.


In this case, it started as a question of automating my workflow, which it tried to write a python script to do the whole thing, without understanding that it can't call on foobar to process or convert things from the command line (or if you can, we did it wrong and abandoned that), and once I reached the point of a successful .dsf extraction but it bombing out at the level checking, that's when I decided - break that off, save a working .dsf extract script, and lets build a separate script for checking levels.

And that was really the turning point when I realized what I had fallen into, and that I needed to build small scripts to call on. So the obvious next step was to build a python script to determine the gain.

I am trying to pour over this to give you specifics, but can't quite yet - but at some point the discussion was developing a script for the gain, and the AI was trying to do it using sox, and I pasted the error and that's when we determined sox can't process dsf files. So then it gave me a command to run to check levels using ffmpeg, which we tested on one track (we were still extracting .dsf tracks at that point) (ffmpeg -i "M:\Staging\SACDout\Stereo\In Deep & Nexus Pt 1\Stereo\01 - God Gave Rock and Roll to You.dsf" -af "astats=metadata=1:reset=1" -f null -) and it returned values that made no sense, Peak level dB: -22.294518, Peak level dB: -22.010158



Oh....then we ran into problems finding the files, because of the folder structure that sacd_extract.exe creates. In my staging folder (M:\Staging\SACDout) it created a Stereo folder for stereo output and Multichannel folder for multi out - but sacd_extract automatically will create in it's landing spot a folder for the disc, and a folder for the stereo, so I had these embedded folders I didn't want, that had names that would change, based on the disc name, and for multichannel based on number of channels (5ch or 6ch). So I asked it to build me a script that would move the files up to the parent folder and wipe those subfolders out. And then we got back to the gain issue.

After that - I asked it to clarify about a comment it made earlier about a fork of sox that could handle dsf - but I'll scroll past that, the outcome of that was I found a sox fork that gave me 0db readings for everything, so I abandoned that and restored the sox we had that doesn't deal with dsf.

So we were stuck, we had foobar that couldn't be called on to automate this process, we had ffmpeg giving us levels 16dB lower than we were expecting, and we had a sox fork that gave us 0dB level readings. (At some point I manually processed the files to determine the level we were looking for was -6.25 for L and -6.94 for R, and we confirmed that when using ffmpeg to convert the .dsf to wav that was the peak level we got, despite the -22 readings).

At this point Grok was suggesting an initial conversion to a temp .wav to check levels, then a new conversion with the gain value. Which I didn't like, because that's just automating extra steps we shouldn't need. So I asked it a question:

(finally, we get to an actual query)

Converting all our .dsf files to .wav as a reference to determine levels is a significant time waste when we should be able to read levels directly from the .dsf file. How come the DR Meter (foo_dr_meter) can accurately determine levels on a .dsf file without conversion, but we can't come up with a method?

And it responded:

You’re absolutely right—converting every .dsf to WAV just to check levels is inefficient and frustrating, especially when foobar2000’s DR Meter (foo_dynamic_range) can analyze .dsf files directly and give accurate peaks (-6.25/-6.94 dBFS) without any intermediate steps. It’s a fair question: why can’t we replicate that? The answer lies in how foobar2000 handles DSD internally versus the limitations of command-line tools like FFmpeg and SoX. Let’s break this down, figure out why DR Meter succeeds, and find a way to match it without conversions.

---

Why DR Meter Works Directly​

• foobar2000 Architecture:
  • Uses foo_input_sacd to decode .dsf files. This plugin converts DSD to PCM in real-time within foobar2000’s pipeline, applying a standard scaling (likely -6 dB SACD-to-PCM offset per SACD specs).
  • DR Meter (foo_dynamic_range) then analyzes this PCM stream, measuring true peaks and RMS relative to 0 dBFS.
• Key Advantage: The conversion and analysis happen seamlessly in memory—no temp files, no external CLI. The plugin’s DSD-to-PCM process is tuned for SACD playback and analysis, ensuring peaks align with mastered levels (e.g., -6 dBFS).

Your Results​

• .dsf in foobar2000:
  • Peak: -6.25 dBFS (Left), -6.94 dBFS (Right)
  • RMS: -20.30 dB (Left), -20.84 dB (Right)
• Trusted benchmark we need to match.

---

Why CLI Tools Struggle​

1. FFmpeg:
   • Decodes .dsf to PCM correctly (proven by WAV output matching foobar2000), but the astats filter reports peaks at -22 dBFS—16 dB too low.
   • Likely issue: astats misreferences the PCM scale or applies an undocumented attenuation for DSD’s noise floor, despite the raw PCM being correct.
2. SoX (Original 14.4.2):
   • No .dsf support—fails outright.
3. SoX DSD Fork:
   • Reads .dsf but normalizes to 0 dBFS, misinterpreting DSD levels entirely.
4. Common Problem:
   • CLI tools lack foobar2000’s integrated DSD handling. They either don’t support .dsf natively or mishandle the DSD-to-PCM scaling in analysis mode.

---

How DR Meter Does It​

• Source Insight: foo_input_sacd (open-source on GitHub: https://github.com/dkrey/foo_input_sacd) uses a DSD-to-PCM converter with a fixed gain (typically -6 dB) to map 0 dB SACD to -6 dBFS PCM, avoiding clipping while preserving signal integrity.
• DR Meter: Written by Peter Pawlowski (foobar2000’s creator), it hooks into this PCM stream post-conversion, using a precise peak detection algorithm (likely ReplayGain-based) to report dBFS levels.
• No Files: All processing is in-memory, leveraging foobar2000’s playback chain.

Why We Can’t Call It Directly​

• Foobar2000 v1.6.16 CLI doesn’t expose DR Meter or foo_input_sacd analysis via command line. Components like foo_run can trigger playback commands, but not export peak data.

---

Finding a Direct .dsf Solution​

We need a CLI tool or method that:

• Reads .dsf natively.
• Converts DSD to PCM with the same scaling as foo_input_sacd (-6 dB offset).
• Reports accurate peaks without temp files.

Option 1: Reverse-Engineer foo_input_sacd​

• Idea: Use its DSD decoding logic standalone.
• Reality: Requires compiling the plugin’s C++ code into a CLI tool—complex and time-intensive (needs Visual Studio, audio libs).

Option 2: FFmpeg with Correct Scaling​

• Discovery: FFmpeg’s WAV output matches foobar2000, but astats doesn’t. Can we fix astats or bypass it?
• Test: Analyze FFmpeg’s PCM output directly without astats:
  text
  CollapseWrapCopy
  ffmpeg -i "M:\Staging\SACDout\Stereo\01 - God Gave Rock and Roll to You.dsf" -f f32le -ar 88200 - | sox -t raw -r 88200 -e float -b 32 -c 2 - -n stats
  • -f f32le: Outputs raw 32-bit float PCM.
  • Pipes to SoX for stats on the fly (no WAV file).
• Test Request:
  • Run the command above.
  • Share SoX’s Pk lev dB output.
  • Tell me: “I tested FFmpeg pipe to SoX. Peaks were [X dBFS].”

Option 3: Alternative CLI Tool​

• dsdinfo: A lightweight DSD analyzer (from sacd-ripper tools).
  • Limited availability, no peak level output—mostly metadata.
• libsndfile CLI: sndfile-info reads .dsf with recent builds, but no peak analysis.
• Verdict: None match DR Meter’s precision out of the box.

---

Why Option 2 Might Work​

• FFmpeg’s DSD-to-PCM decoding is correct (WAV test proved it).
• Piping raw PCM to SoX avoids astats’s scaling issue and temp files.
• SoX’s stats on PCM should match foobar2000 if the pipe preserves levels.

Expected Output​

• Pk lev dB around -6.25/-6.94 dBFS for Left/Right, aligning with DR Meter.

---

Next Steps​

1. Run the Test:
   • Try the FFmpeg-to-SoX pipe command.
   • Share the SoX output.
2. If It Works:
   • I’ll script analyze_peaks.py to pipe all .dsf files this way.
3. If Not:
   • We’ll explore scripting foobar2000 with a component (e.g., foo_run + log output) or accept the WAV conversion trade-off.

You’re right—we should read .dsf directly like DR Meter. This pipe test could be our breakthrough—run it and let me know the results!


After a little troubleshooting to deal with a .dll issue with sox, we had a successful test with the option 2 command


E:\iso2dsd>ffmpeg -i "M:\Staging\SACDout\Stereo\01 - God Gave Rock and Roll to You.dsf" -f f32le -ar 88200 - | "C:\Program Files (x86)\sox-14-4-2\sox.exe" -t raw -r 88200 -e float -b 32 -c 2 - -n stats
ffmpeg version 7.1-full_build-www.gyan.dev Copyright (c) 2000-2024 the FFmpeg developers built with gcc 14.2.0 (Rev1, Built by MSYS2 project) configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libaribcaption --enable-libdav1d --enable-libdavs2 --enable-libopenjpeg --enable-libquirc --enable-libuavs3d --enable-libxevd --enable-libzvbi --enable-libqrencode --enable-librav1e --enable-libsvtav1 --enable-libvvenc --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxeve --enable-libxvid --enable-libaom --enable-libjxl --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-dxva2 --enable-d3d11va --enable-d3d12va --enable-ffnvcodec --enable-libvpl --enable-nvdec --enable-nvenc --enable-vaapi --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libcodec2 --enable-libilbc --enable-libgsm --enable-liblc3 --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint libavutil 59. 39.100 / 59. 39.100 libavcodec 61. 19.100 / 61. 19.100 libavformat 61. 7.100 / 61. 7.100 libavdevice 61. 3.100 / 61. 3.100 libavfilter 10. 4.100 / 10. 4.100 libswscale 8. 3.100 / 8. 3.100 libswresample 5. 3.100 / 5. 3.100 libpostproc 58. 3.100 / 58. 3.100[dsf @ 000002d3638d97c0] Estimating duration from bitrate, this may be inaccurateInput #0, dsf, from 'M:\Staging\SACDout\Stereo\01 - God Gave Rock and Roll to You.dsf': Metadata: title : God Gave Rock and Roll to You album : In Deep & Nexus Pt 1 artist : Argent album_artist : Argent PERFORMER : Argent composer : Ballard TSRC : USSM17300809 publisher : Vocalion Ltd copyright : Sony Music disc : 1/1 genre : R&B track : 1/13 date : 2019-17-11 Duration: 00:06:43.91, start: 0.000000, bitrate: 5644 kb/s Stream #0:0: Audio: dsd_lsbf_planar, 352800 Hz, stereo, fltp, 5644 kb/sStream mapping: Stream #0:0 -> #0:0 (dsd_lsbf_planar (native) -> pcm_f32le (native))Press [q] to stop, [?] for helpOutput #0, f32le, to 'pipe:': Metadata: title : God Gave Rock and Roll to You album : In Deep & Nexus Pt 1 artist : Argent album_artist : Argent PERFORMER : Argent composer : Ballard TSRC : USSM17300809 publisher : Vocalion Ltd copyright : Sony Music disc : 1/1 genre : R&B track : 1/13 date : 2019-17-11 encoder : Lavf61.7.100 Stream #0:0: Audio: pcm_f32le, 88200 Hz, stereo, flt, 5644 kb/s Metadata: encoder : Lavc61.19.100 pcm_f32le[out#0/f32le @ 000002d3638ebb80] video:0KiB audio:278317KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 0.000000%size= 278317KiB time=00:06:43.90 bitrate=5644.8kbits/s speed= 117x Overall Left RightDC offset -0.000000 -0.000000 -0.000000Min level -0.457259 -0.457259 -0.419144Max level 0.486967 0.486967 0.449288Pk lev dB -6.25 -6.25 -6.95RMS lev dB -23.55 -23.29 -23.83RMS Pk dB -16.75 -16.87 -16.75RMS Tr dB -80.74 -77.80 -80.74Crest factor - 7.12 6.98Flat factor 0.00 0.00 0.00Pk count 2 2 2Bit-depth 31/32 31/32 31/32Num samples 35.6MLength s 403.907Scale max 1.000000Window s 0.050


Which included peak values we expected to see of -6.25 and -6.95 (just a little off of the -6.94 from our test, but within a margin of error)

And then it wrote me the first version of the script I pasted above.