Built a macOS bit-perfect player with measurement tools. Looking for feedback and some tests

[RikyPate]

Hi!

I've been working on a macOS audio player focused on bit-perfect playback, and I've reached the point where I need perspectives beyond my own. This is my first post here, and I'd like to start with an open discussion about the design choices and tradeoffs I've made. If there's enough interest, I'm also looking for a small group willing to test it on their own systems.

The core design question I'd like to put to this community:

Most audio players for macOS advertise "bit-perfect" playback, but very few include any way to verify the claim. I built mine with a set of measurement tools specifically to close that gap. The question I'd like feedback on: is the approach sound, or am I missing something?

Here's what the player does:

The signal path has zero processing between the file and the DAC. No EQ, no DSP, no upsampling, no volume control (gain is always unity). This isn't a missing feature list, it's the point: the only job of the player is to deliver unmodified samples to the hardware.

Two playback paths: a direct CoreAudio IOProc with hog mode and non-mixable format negotiation when the DAC supports it, and an AVAudioEngine fallback for devices that don't (built-in output, Bluetooth, AirPlay). The path selection is automatic. The user always knows which one is active.

The measurement/verification side (where I'd value this forum's input the most):

• Bit-Perfect Test (BPT): Sample-by-sample comparison of output vs. loopback input, aligned by calibrated latency via cross-correlation. Binary pass/fail: either every sample matches or it doesn't. I'd be very curious to hear if anyone sees flaws in this methodology, or knows of edge cases where this kind of test gives false confidence.
• Stream Inspector: Real-time status of the signal chain. Reports whether the path is bit-perfect, if the fade envelope is active (the player uses a 50 ms gain ramp for click-free transitions, so bit-perfect is technically broken during pause, seek, and track skip - track changes are gapless), if synthetic fill was injected, or if a buffer underrun occurred. For DSD over DoP, it tracks marker alternation and flags phase errors. It also shows effective bit depth and DAC sync state, and logs every anomaly with sub-sample timestamps.
• Signal Generator: Sine, beat (two detuned tones), Lissajous patterns, correlated noise, impulse bursts, 0 dBFS reference. Everything is routed through the normal playback path (same IOProc, same ring buffer, same DAC output), so you're measuring the actual signal chain, not a synthetic shortcut.
• Measurement Engine: dBFS RMS + peak with A-weighting and C-weighting (IEC 61672 biquad cascade), 16384-point FFT with parabolic interpolation for sub-Hz frequency accuracy, L/R phase via Goertzel single-bin DFT, loopback latency calibration.
• Loopback Capture: Dedicated AUHAL input-only unit, independent from the playback engine.
• DAC Diagnostic Panel: Enumerates every physical stream format the DAC exposes (sample type, bit depth, rate ranges, mixable vs. non-mixable). Shows the currently active format and the maximum non-mixable capability.
• Audio Analysis: Offline FFT spectrum analysis with “fake” hi-res detection (identifies files that claim high resolution but carry no energy above a lower-resolution cutoff frequency).
• Vectorscope: Metal-accelerated, Tektronix-style, 2048-tap FIR decimation filter, dual-channel.

Format support: FLAC, WAV, AIFF, ALAC, MP3 (aargh!), AAC, DSF, DFF, SACD ISO (full Scarlet Book parser with DST decoding), WavPack (PCM and DSD, lossless and hybrid), CUE sheets (single-file and multi-file). DSD playback via DoP, up to DSD512.

Some open questions I'd genuinely like feedback on:

1. The BPT relies on loopback capture + cross-correlation for latency alignment. Are there known pitfalls with this approach on macOS (beyond the obvious fact that it only tests the digital path up to the loopback point)?
2. The fade envelope means the player is technically not bit-perfect for roughly 50 ms during transitions. I chose this tradeoff to avoid clicks. Is there a better approach that doesn't compromise the signal during normal playback?
3. For DSD, the player uses DoP exclusively (no native DSD over USB). Is there significant demand for native DSD on macOS, or is DoP generally considered adequate?
4. The "fake hi-res detection" uses spectral energy analysis above the expected Nyquist frequency of the source resolution. Anyone aware of better heuristics for this, or cases where this method gives false positives?

If you'd like to try it, I'm looking for a small group of macOS users to test it before release. Ideal setup: macOS 14+, a USB DAC with exclusive mode support, and a local library with a variety of formats. If you also have an audio interface for loopback testing, that's especially useful for validating the measurement tools. Testers get early access and a permanent license at launch: DM me with your setup (Mac model, DAC, formats you play) if you're interested, and I'll be happy to follow up!

Looking forward to hearing what this community thinks, whether or not you want to test it.

Thank you!

EDIT: you can test a beta version of VeraVox here: VeraVox (beta program)

 

[RickS]

Welcome to ASR!

Perhaps you could post a short video to demonstrate your app?

If you plan to monetize it, you will need to apply for a commercial account here. Please read the following terms:

Rules for Audio Dealers, Manufacturers, Members with Commercial Interest. This includes any Guest Contributors/Reviewer with Commercial endorsement

Audio Science Review Rules for Dealers, Manufacturers, Reviewers and Members of Industry. We encourage participation from members of industry in the forum. So please feel welcome here. We expect you to post with highest levels of professionalism. You are representing an industry and it is...

www.audiosciencereview.com

 

[RikyPate]

Welcome to ASR!

Perhaps you could post a short video to demonstrate your app?

If you plan to monetize it, you will need to apply for a commercial account here. Please read the following terms:

Rules for Audio Dealers, Manufacturers, Members with Commercial Interest. This includes any Guest Contributors/Reviewer with Commercial endorsement

Audio Science Review Rules for Dealers, Manufacturers, Reviewers and Members of Industry. We encourage participation from members of industry in the forum. So please feel welcome here. We expect you to post with highest levels of professionalism. You are representing an industry and it is...

www.audiosciencereview.com

Thanks @RickS and thanks for the welcome.

A video is a great idea, I'll put one together. In the meantime, I'll add some (no branded) screenshots.
It'll be more effective than a wall of text for showing what the tools actually do

On the commercial account: good to know, thanks for pointing me to the rules. The player isn't released yet and I honestly wasn't sure if this fell under commercial activity at this stage (no name, no link, no product page). I'll look into the commercial account process. In the meantime, if the thread needs to be moved or adjusted, just let me know.

 

[RikyPate]

Thanks to the invaluable feedback from some of you, VeraVox has now reached a stable version, ready for more extensive testing.
If any of you would like to contribute to its development, your participation would be very welcome and much appreciated.

You can download the installer at this link: VeraVox beta program

The package is a notarized .dmg file and does not require any invasive installation. Any future beta updates will be handled automatically when the app starts. This is a full-featured version, which will remain fully functional until May 31, 2026 (unless the beta period is extended).

I want to thank everyone who takes the time to try it out and share their insights.

 

[Magos Vox]

Fascinating! Greetings from the other pond. Fellow Vox-er, even, by happy accident of naming. I'm genuinely gladdened to see that you independently came to the same conclusion that crossfade is technically not bit-perfect. Excellent transparency posture.

I'm working on the Android side of this niche, but I reckon your battlefield is quite different. Still, if you ever want to compare notes on fade strategies, click-avoidance ramps, or DSD transport, drop a line. Plenty of room for both of us in this niche.

Looking forward to seeing where VeraVox goes!

 

[RikyPate]

Fascinating! Greetings from the other pond. Fellow Vox-er, even, by happy accident of naming. I'm genuinely gladdened to see that you independently came to the same conclusion that crossfade is technically not bit-perfect. Excellent transparency posture.

I'm working on the Android side of this niche, but I reckon your battlefield is quite different. Still, if you ever want to compare notes on fade strategies, click-avoidance ramps, or DSD transport, drop a line. Plenty of room for both of us in this niche.

Looking forward to seeing where VeraVox goes!

Thanks Magos!

Yes, it’s definitely a happy coincidence and a great omen!

It’ll be a pleasure to share some thoughts with you. As you might have seen in the press kit, I’ve made some rather "extreme" choices: I know my player won't be for those who love software DSP (no EQ, no volume), but I believe it will be appreciated by those who want full control over their source.

Let’s stay in touch, thanks!

 

[Dialectic]

Hi!

I've been working on a macOS audio player focused on bit-perfect playback, and I've reached the point where I need perspectives beyond my own. This is my first post here, and I'd like to start with an open discussion about the design choices and tradeoffs I've made. If there's enough interest, I'm also looking for a small group willing to test it on their own systems.

The core design question I'd like to put to this community:

Most audio players for macOS advertise "bit-perfect" playback, but very few include any way to verify the claim. I built mine with a set of measurement tools specifically to close that gap. The question I'd like feedback on: is the approach sound, or am I missing something?

Here's what the player does:

The signal path has zero processing between the file and the DAC. No EQ, no DSP, no upsampling, no volume control (gain is always unity). This isn't a missing feature list, it's the point: the only job of the player is to deliver unmodified samples to the hardware.

Two playback paths: a direct CoreAudio IOProc with hog mode and non-mixable format negotiation when the DAC supports it, and an AVAudioEngine fallback for devices that don't (built-in output, Bluetooth, AirPlay). The path selection is automatic. The user always knows which one is active.

The measurement/verification side (where I'd value this forum's input the most):

• Bit-Perfect Test (BPT): Sample-by-sample comparison of output vs. loopback input, aligned by calibrated latency via cross-correlation. Binary pass/fail: either every sample matches or it doesn't. I'd be very curious to hear if anyone sees flaws in this methodology, or knows of edge cases where this kind of test gives false confidence.
• Stream Inspector: Real-time status of the signal chain. Reports whether the path is bit-perfect, if the fade envelope is active (the player uses a 50 ms gain ramp for click-free transitions, so bit-perfect is technically broken during pause, seek, and track skip - track changes are gapless), if synthetic fill was injected, or if a buffer underrun occurred. For DSD over DoP, it tracks marker alternation and flags phase errors. It also shows effective bit depth and DAC sync state, and logs every anomaly with sub-sample timestamps.
• Signal Generator: Sine, beat (two detuned tones), Lissajous patterns, correlated noise, impulse bursts, 0 dBFS reference. Everything is routed through the normal playback path (same IOProc, same ring buffer, same DAC output), so you're measuring the actual signal chain, not a synthetic shortcut.
• Measurement Engine: dBFS RMS + peak with A-weighting and C-weighting (IEC 61672 biquad cascade), 16384-point FFT with parabolic interpolation for sub-Hz frequency accuracy, L/R phase via Goertzel single-bin DFT, loopback latency calibration.
• Loopback Capture: Dedicated AUHAL input-only unit, independent from the playback engine.
• DAC Diagnostic Panel: Enumerates every physical stream format the DAC exposes (sample type, bit depth, rate ranges, mixable vs. non-mixable). Shows the currently active format and the maximum non-mixable capability.
• Audio Analysis: Offline FFT spectrum analysis with “fake” hi-res detection (identifies files that claim high resolution but carry no energy above a lower-resolution cutoff frequency).
• Vectorscope: Metal-accelerated, Tektronix-style, 2048-tap FIR decimation filter, dual-channel.

Format support: FLAC, WAV, AIFF, ALAC, MP3 (aargh!), AAC, DSF, DFF, SACD ISO (full Scarlet Book parser with DST decoding), WavPack (PCM and DSD, lossless and hybrid), CUE sheets (single-file and multi-file). DSD playback via DoP, up to DSD512.

Some open questions I'd genuinely like feedback on:

1. The BPT relies on loopback capture + cross-correlation for latency alignment. Are there known pitfalls with this approach on macOS (beyond the obvious fact that it only tests the digital path up to the loopback point)?
2. The fade envelope means the player is technically not bit-perfect for roughly 50 ms during transitions. I chose this tradeoff to avoid clicks. Is there a better approach that doesn't compromise the signal during normal playback?
3. For DSD, the player uses DoP exclusively (no native DSD over USB). Is there significant demand for native DSD on macOS, or is DoP generally considered adequate?
4. The "fake hi-res detection" uses spectral energy analysis above the expected Nyquist frequency of the source resolution. Anyone aware of better heuristics for this, or cases where this method gives false positives?

If you'd like to try it, I'm looking for a small group of macOS users to test it before release. Ideal setup: macOS 14+, a USB DAC with exclusive mode support, and a local library with a variety of formats. If you also have an audio interface for loopback testing, that's especially useful for validating the measurement tools. Testers get early access and a permanent license at launch: DM me with your setup (Mac model, DAC, formats you play) if you're interested, and I'll be happy to follow up!

Looking forward to hearing what this community thinks, whether or not you want to test it.

Thank you!

I was considering vibe-coding something like this and making it available for free.

But good luck with your commercial project!

 

[RikyPate]

I was considering vibe-coding something like this and making it available for free.

But good luck with your commercial project!

Thanks for the feedback!

To be honest, this project started as a personal challenge. I’m a passionate listener myself and I felt there was something missing for Mac, so I decided to build exactly what I was looking for. I’ve been lucky enough to involve some very talented people, far more expert than me, who helped me turn the idea into reality. After months of hard work, I realized that what we were building could be interesting for other enthusiasts too.

It’s been a long journey to get here and I’m just excited to see where it goes

I really appreciate the good luck wish, thanks!

 

[Dialectic]

If what you make is good, you will have accomplished something remarkable.

Roon, JRiver, Audirvana, and Pine Player have all become bloated, buggy, and, frankly, terrible under MacOS.

I run Foobar because I want something that just plays my music. But I want SACD ISO playback and maybe, just maybe, usable library functionality for my 20,000+ classical discs.

 

[RikyPate]

If what you make is good, you will have accomplished something remarkable.

Roon, JRiver, Audirvana, and Pine Player have all become bloated, buggy, and, frankly, terrible under MacOS.

I run Foobar because I want something that just plays my music. But I want SACD ISO playback and maybe, just maybe, usable library functionality for my 20,000+ classical discs.

Thank you, really appreciate that. SACD ISO is already fully supported: complete Scarlet Book parser, DST decoding, native DSD via DoP up to DSD512. No conversion unless your DAC needs it. Library is DB-driven with full-text search, composer browsing (built with classical in mind), smart playlists, and folder navigation.

I'd love your take on it... if so, let me know your comments please! (VeraVox Beta Program)

 

[JFMV]

Your approach is already more rigorous than most “bit-perfect” players. The verification angle is the right differentiator. The core design is sound, but a few areas could be strengthened to avoid false confidence and make the tool genuinely diagnostic rather than just confirmatory.


1. Bit-Perfect Test (BPT)
Loopback + cross-correlation is valid, but it only proves the signal is preserved up to the capture point under current conditions. It does not guarantee that the device path (USB transport, DAC internal processing, clock domain) is untouched.

A few suggestions:

Consider distinguishing between:
- bit-exact (strict equality)
- bit-transparent (allowing ±1 LSB differences, dither, padding, etc.)
- Add error analysis rather than just pass/fail:
- error histogram
- pattern detection (random vs structured → dither vs SRC)
- Include a deterministic test signal (e.g. PRBS) in addition to audio material.
- Run both short and long-duration tests to expose clock drift between input and output devices.

2. Latency alignment via cross-correlation
This works well in general, but can fail with:
- periodic signals (pure tones)
- low-energy signals
- filtered content

You might improve robustness by:
- using a dedicated calibration signal (impulse + pseudo-random noise)
- correlation with edge/impulse detection

3. Fade envelope (50 ms)
The tradeoff is reasonable, but it would be worth exposing it explicitly:
- Strict mode: no fades, possible clicks
- Safe mode: current behavior
- optionally a “smart” mode (fade only on discontinuities)
This avoids criticism from users who expect absolute purity at all times.

4. Loopback limitations
It would help to explicitly state (and maybe visualize) that:
- the BPT validates the measured digital path, not the analog output
- DACs or drivers may still apply hidden SRC or internal processing

This is more about credibility than functionality.

5. DSD over DoP
Your choice is defensible on macOS. Native DSD is often driver-dependent and less portable.
If anything, you could strengthen the diagnostics:
- DoP marker integrity issues
- flag marker phase errors or dropouts

I would not prioritize native DSD unless testers specifically request it.

6. “Fake hi-res” detection
Spectral energy above a cutoff is a useful heuristic, but fragile:
- acoustic recordings often have little ultrasonic content
- some valid masters are bandwidth-limited
- noise injection or filtering can mislead the detector

Instead of a binary label, consider:
- a “consistency score”
- combining:

• spectral slope
• brickwall detection
• energy distribution across bands

7. Measurement engine / FFT
16384 points is fine for real-time, but you might add:
- higher FFT sizes (64k, 128k) for offline analysis
- multiple window options (Hann, Blackman-Harris, flat-top)
- averaging modes

8. Signal generator
Very useful as-is. You could extend it with:
- multitone (IMD testing)
- logarithmic sweep
- MLS for impulse/response measurements

9. Buffering / underrun diagnostics
Since you already log underruns, you could go further:
- track IOProc timing variance
- expose a simple “buffer stability” metric or histogram

10. DAC diagnostics
Listing supported formats is good. A next step would be:
- active probing (try formats and verify via loopback what actually happens)

11. High-level suggestion
You are very close to something more than a player. A built-in “self-test suite” could be extremely valuable:
- bit-perfect validation
- SRC detection
- buffer stability
- DSD integrity
→ generate a simple report for the user

Overall, the architecture is solid. The main improvement is shifting from binary claims (“bit-perfect / not”) to measured, contextualized behavior. That would make your player not just credible, but genuinely useful as an audio verification tool.

 

[Dialectic]

Your approach is already more rigorous than most “bit-perfect” players. The verification angle is the right differentiator. The core design is sound, but a few areas could be strengthened to avoid false confidence and make the tool genuinely diagnostic rather than just confirmatory.


1. Bit-Perfect Test (BPT)
Loopback + cross-correlation is valid, but it only proves the signal is preserved up to the capture point under current conditions. It does not guarantee that the device path (USB transport, DAC internal processing, clock domain) is untouched.

A few suggestions:

Consider distinguishing between:
- bit-exact (strict equality)
- bit-transparent (allowing ±1 LSB differences, dither, padding, etc.)
- Add error analysis rather than just pass/fail:
- error histogram
- pattern detection (random vs structured → dither vs SRC)
- Include a deterministic test signal (e.g. PRBS) in addition to audio material.
- Run both short and long-duration tests to expose clock drift between input and output devices.

2. Latency alignment via cross-correlation
This works well in general, but can fail with:
- periodic signals (pure tones)
- low-energy signals
- filtered content

You might improve robustness by:
- using a dedicated calibration signal (impulse + pseudo-random noise)
- correlation with edge/impulse detection

3. Fade envelope (50 ms)
The tradeoff is reasonable, but it would be worth exposing it explicitly:
- Strict mode: no fades, possible clicks
- Safe mode: current behavior
- optionally a “smart” mode (fade only on discontinuities)
This avoids criticism from users who expect absolute purity at all times.

4. Loopback limitations
It would help to explicitly state (and maybe visualize) that:
- the BPT validates the measured digital path, not the analog output
- DACs or drivers may still apply hidden SRC or internal processing

This is more about credibility than functionality.

5. DSD over DoP
Your choice is defensible on macOS. Native DSD is often driver-dependent and less portable.
If anything, you could strengthen the diagnostics:
- DoP marker integrity issues
- flag marker phase errors or dropouts

I would not prioritize native DSD unless testers specifically request it.

6. “Fake hi-res” detection
Spectral energy above a cutoff is a useful heuristic, but fragile:
- acoustic recordings often have little ultrasonic content
- some valid masters are bandwidth-limited
- noise injection or filtering can mislead the detector

Instead of a binary label, consider:
- a “consistency score”
- combining:

• spectral slope
• brickwall detection
• energy distribution across bands

7. Measurement engine / FFT
16384 points is fine for real-time, but you might add:
- higher FFT sizes (64k, 128k) for offline analysis
- multiple window options (Hann, Blackman-Harris, flat-top)
- averaging modes

8. Signal generator
Very useful as-is. You could extend it with:
- multitone (IMD testing)
- logarithmic sweep
- MLS for impulse/response measurements

9. Buffering / underrun diagnostics
Since you already log underruns, you could go further:
- track IOProc timing variance
- expose a simple “buffer stability” metric or histogram

10. DAC diagnostics
Listing supported formats is good. A next step would be:
- active probing (try formats and verify via loopback what actually happens)

11. High-level suggestion
You are very close to something more than a player. A built-in “self-test suite” could be extremely valuable:
- bit-perfect validation
- SRC detection
- buffer stability
- DSD integrity
→ generate a simple report for the user

Overall, the architecture is solid. The main improvement is shifting from binary claims (“bit-perfect / not”) to measured, contextualized behavior. That would make your player not just credible, but genuinely useful as an audio verification tool.

Thank you, ChatGPT!

 

[Josh83]

Hi!

I've been working on a macOS audio player focused on bit-perfect playback, and I've reached the point where I need perspectives beyond my own. This is my first post here, and I'd like to start with an open discussion about the design choices and tradeoffs I've made. If there's enough interest, I'm also looking for a small group willing to test it on their own systems.

The core design question I'd like to put to this community:

Most audio players for macOS advertise "bit-perfect" playback, but very few include any way to verify the claim. I built mine with a set of measurement tools specifically to close that gap. The question I'd like feedback on: is the approach sound, or am I missing something?

Here's what the player does:

The signal path has zero processing between the file and the DAC. No EQ, no DSP, no upsampling, no volume control (gain is always unity). This isn't a missing feature list, it's the point: the only job of the player is to deliver unmodified samples to the hardware.

Two playback paths: a direct CoreAudio IOProc with hog mode and non-mixable format negotiation when the DAC supports it, and an AVAudioEngine fallback for devices that don't (built-in output, Bluetooth, AirPlay). The path selection is automatic. The user always knows which one is active.

The measurement/verification side (where I'd value this forum's input the most):

• Bit-Perfect Test (BPT): Sample-by-sample comparison of output vs. loopback input, aligned by calibrated latency via cross-correlation. Binary pass/fail: either every sample matches or it doesn't. I'd be very curious to hear if anyone sees flaws in this methodology, or knows of edge cases where this kind of test gives false confidence.
• Stream Inspector: Real-time status of the signal chain. Reports whether the path is bit-perfect, if the fade envelope is active (the player uses a 50 ms gain ramp for click-free transitions, so bit-perfect is technically broken during pause, seek, and track skip - track changes are gapless), if synthetic fill was injected, or if a buffer underrun occurred. For DSD over DoP, it tracks marker alternation and flags phase errors. It also shows effective bit depth and DAC sync state, and logs every anomaly with sub-sample timestamps.
• Signal Generator: Sine, beat (two detuned tones), Lissajous patterns, correlated noise, impulse bursts, 0 dBFS reference. Everything is routed through the normal playback path (same IOProc, same ring buffer, same DAC output), so you're measuring the actual signal chain, not a synthetic shortcut.
• Measurement Engine: dBFS RMS + peak with A-weighting and C-weighting (IEC 61672 biquad cascade), 16384-point FFT with parabolic interpolation for sub-Hz frequency accuracy, L/R phase via Goertzel single-bin DFT, loopback latency calibration.
• Loopback Capture: Dedicated AUHAL input-only unit, independent from the playback engine.
• DAC Diagnostic Panel: Enumerates every physical stream format the DAC exposes (sample type, bit depth, rate ranges, mixable vs. non-mixable). Shows the currently active format and the maximum non-mixable capability.
• Audio Analysis: Offline FFT spectrum analysis with “fake” hi-res detection (identifies files that claim high resolution but carry no energy above a lower-resolution cutoff frequency).
• Vectorscope: Metal-accelerated, Tektronix-style, 2048-tap FIR decimation filter, dual-channel.

Format support: FLAC, WAV, AIFF, ALAC, MP3 (aargh!), AAC, DSF, DFF, SACD ISO (full Scarlet Book parser with DST decoding), WavPack (PCM and DSD, lossless and hybrid), CUE sheets (single-file and multi-file). DSD playback via DoP, up to DSD512.

Some open questions I'd genuinely like feedback on:

1. The BPT relies on loopback capture + cross-correlation for latency alignment. Are there known pitfalls with this approach on macOS (beyond the obvious fact that it only tests the digital path up to the loopback point)?
2. The fade envelope means the player is technically not bit-perfect for roughly 50 ms during transitions. I chose this tradeoff to avoid clicks. Is there a better approach that doesn't compromise the signal during normal playback?
3. For DSD, the player uses DoP exclusively (no native DSD over USB). Is there significant demand for native DSD on macOS, or is DoP generally considered adequate?
4. The "fake hi-res detection" uses spectral energy analysis above the expected Nyquist frequency of the source resolution. Anyone aware of better heuristics for this, or cases where this method gives false positives?

If you'd like to try it, I'm looking for a small group of macOS users to test it before release. Ideal setup: macOS 14+, a USB DAC with exclusive mode support, and a local library with a variety of formats. If you also have an audio interface for loopback testing, that's especially useful for validating the measurement tools. Testers get early access and a permanent license at launch: DM me with your setup (Mac model, DAC, formats you play) if you're interested, and I'll be happy to follow up!

Looking forward to hearing what this community thinks, whether or not you want to test it.

Thank you!

Very cool. Just gave it a try. My only feedback so far is that (unless I'm missing something), the playback workflow is a little awkward. Right now, it seems like you need to add an album from your library to the playlist, then click the track in the playlist to begin playback. It would be nice if you could play right from the album entry in the library, rather than needing the intermediate playlist step. Apologies if I missed some obvious way to do this already.

 

[RikyPate]

Your approach is already more rigorous than most “bit-perfect” players. The verification angle is the right differentiator. The core design is sound, but a few areas could be strengthened to avoid false confidence and make the tool genuinely diagnostic rather than just confirmatory.


1. Bit-Perfect Test (BPT)
Loopback + cross-correlation is valid, but it only proves the signal is preserved up to the capture point under current conditions. It does not guarantee that the device path (USB transport, DAC internal processing, clock domain) is untouched.

A few suggestions:

Consider distinguishing between:
- bit-exact (strict equality)
- bit-transparent (allowing ±1 LSB differences, dither, padding, etc.)
- Add error analysis rather than just pass/fail:
- error histogram
- pattern detection (random vs structured → dither vs SRC)
- Include a deterministic test signal (e.g. PRBS) in addition to audio material.
- Run both short and long-duration tests to expose clock drift between input and output devices.

2. Latency alignment via cross-correlation
This works well in general, but can fail with:
- periodic signals (pure tones)
- low-energy signals
- filtered content

You might improve robustness by:
- using a dedicated calibration signal (impulse + pseudo-random noise)
- correlation with edge/impulse detection

3. Fade envelope (50 ms)
The tradeoff is reasonable, but it would be worth exposing it explicitly:
- Strict mode: no fades, possible clicks
- Safe mode: current behavior
- optionally a “smart” mode (fade only on discontinuities)
This avoids criticism from users who expect absolute purity at all times.

4. Loopback limitations
It would help to explicitly state (and maybe visualize) that:
- the BPT validates the measured digital path, not the analog output
- DACs or drivers may still apply hidden SRC or internal processing

This is more about credibility than functionality.

5. DSD over DoP
Your choice is defensible on macOS. Native DSD is often driver-dependent and less portable.
If anything, you could strengthen the diagnostics:
- DoP marker integrity issues
- flag marker phase errors or dropouts

I would not prioritize native DSD unless testers specifically request it.

6. “Fake hi-res” detection
Spectral energy above a cutoff is a useful heuristic, but fragile:
- acoustic recordings often have little ultrasonic content
- some valid masters are bandwidth-limited
- noise injection or filtering can mislead the detector

Instead of a binary label, consider:
- a “consistency score”
- combining:

• spectral slope
• brickwall detection
• energy distribution across bands

7. Measurement engine / FFT
16384 points is fine for real-time, but you might add:
- higher FFT sizes (64k, 128k) for offline analysis
- multiple window options (Hann, Blackman-Harris, flat-top)
- averaging modes

8. Signal generator
Very useful as-is. You could extend it with:
- multitone (IMD testing)
- logarithmic sweep
- MLS for impulse/response measurements

9. Buffering / underrun diagnostics
Since you already log underruns, you could go further:
- track IOProc timing variance
- expose a simple “buffer stability” metric or histogram

10. DAC diagnostics
Listing supported formats is good. A next step would be:
- active probing (try formats and verify via loopback what actually happens)

11. High-level suggestion
You are very close to something more than a player. A built-in “self-test suite” could be extremely valuable:
- bit-perfect validation
- SRC detection
- buffer stability
- DSD integrity
→ generate a simple report for the user

Overall, the architecture is solid. The main improvement is shifting from binary claims (“bit-perfect / not”) to measured, contextualized behavior. That would make your player not just credible, but genuinely useful as an audio verification tool.

Thanks for the feedback. To be honest, it looks like an AI's response to the analysis of my press-kit, but maybe I'm wrong. If that's the case, I apologise. A few quick notes on where things stand:

1-4. BPT, latency, loopback scope. The BPT already does sample-by-sample comparison with error magnitude (not just pass/fail). Latency alignment uses a dedicated calibration burst, so the periodic-signal issue doesn't apply. The scope (digital path only, not analog output) is stated explicitly in the app;

5. DoP marker integrity. Already monitored in real time by the Stream Inspector: per-channel phase continuity (0x05/0xFA alternation), cross-channel alignment, invalid marker detection, phase error logging with sample offsets;

6. Fake hi-res. Not a binary label. File Forensics combines bandwidth collapse, brickwall filter detection, natural rolloff, noise floor, and bit-depth estimation into a contextual verdict. DSD files are explicitly excluded (1-bit PDM, FFT heuristics don't apply);

7. FFT. Dynamic sizing up to 65536 points depending on sample rate, Blackman-Harris 4-term windowing, 50% overlap averaging (up to 2000 windows);

3. Fade. During steady-state playback the fade is completely inactive (gain 1.0, unity fast-path, zero overhead). It only kicks in for transport transitions. A "strict mode" without fades would just produce clicks for no benefit, but I understand the point and I'll think about it;

8. Signal generator extensions. The signal generator is complete for its current scope (6 patterns: sine, beat, Lissajous, noise, impulse, reference). Multitone and log sweep are good suggestions though! I'll consider them for a future update. Have you had a chance to test the measurement engine with a hardware loopback? I'd be curious to hear your results;

11. Self-test suite. Interesting idea. All the pieces exist individually; bundling them into a one-click report is something I'll consider.

I'd love to hear your impressions after spending some time with the app, especially the diagnostic tools. Most of the points above are things you can see in action, and I'd be happy to get your further feedback ;-)

 

[RikyPate]

Very cool. Just gave it a try. My only feedback so far is that (unless I'm missing something), the playback workflow is a little awkward. Right now, it seems like you need to add an album from your library to the playlist, then click the track in the playlist to begin playback. It would be nice if you could play right from the album entry in the library, rather than needing the intermediate playlist step. Apologies if I missed some obvious way to do this already.

Hi Josh, you're absolutely right, that's a UX gap. Right now the library only has "add to playlist" actions, there's no direct "play" from an album or track view. I'll add a play all button to the album header and a double click to play on individual tracks in the next update. Thanks for pointing it out, sometimes you're too deep in the code to notice the obvious workflow friction...my bad ;-)

EDIT: fixed, let me know please

 

[RikyPate]

Beta build 125 is out with a lot of improvements.
Let me know and thank you all!