This is part 4 of a series of articles about ADC. The previous articles are here, here, and here.

In the previous articles, I focused on ADC's claims, its marketing language, and its internal design. But there is another question that matters much, much more than any homepage copy or release-note grandstanding: "How does it actually perform when put beside established codecs at the same target bitrate?"

For this article, I analyzed my own benchmark run, using my own codec benchmark framework that I created specifically for this article, generated on February 15, 2026. The run compared adc, lame, opus, and qaac at a nominal target of 128 kbps across 24 tracks, using GST PEAQ Advanced for objective audio quality measurement, along with SNR and effective bitrate.

To avoid confusion with the earlier spectrogram post: the old spectrogram comparisons were made with ADC v0.82, but this benchmark used the newer (and latest at the time of this writing) ADC 0.84 rev.0 executable. That distinction matters here because someone could otherwise say "this benchmark is outdated because that isn't the latest version."

The encoder versions used here were:

• ADC (generic) v0.84 rev0
• LAME 3.100
• Opus-tools 0.2, using libopus 1.6.1
• qAAC 2.85, Core Audio Tools 7.10.9

The settings were also straightforward:

• ADC was encoded at the requested bitrate, with joint stereo enabled, and with the advertised -h "high quality" mode turned on. Although, as noted in the previous article, that -h flag appears to be a no-op even though the help output presents it as a quality option.
• LAME was run in 128 kbps CBR mode.
• Opus was run with a 128 kbps bitrate target in its normal VBR behavior.
• qaac was run in CVBR 128 mode.

All tracks were normalized to 44,100 Hz 16-bit stereo before encoding and after decoding. All tracks were strictly lossless.

From Spectrogram Check to Formal Benchmark

Back in the second article, I showed various spectrograms. At the time, the argument was pretty simple: ADC showed ugly aliasing in sweeps, spectral holes, and long-term degradation, while the other codecs did not exhibit those problems in an audible way, or at all. That was already informative, but it was still an informal argument. Spectrograms tell you a lot, but they are not the same thing as a benchmark.

This benchmark is useful because it does several things at once:

• keeps all codecs in the same general bitrate class
• measures quality with PEAQ Advanced
• records effective bitrate instead of blindly trusting the requested one
• corrects alignment issues before scoring, so shifted output does not get mistaken for poor audio quality (ooh, foreshadowing)

As a side note, though, I do recognize that ABX is still the best way to test codecs. However, I do not have the patience to ABX every individual file in every codec I am testing here, so PEAQ is the only reasonable choice for me.

What ODG Means

The most important metric in the report is PEAQ ODG, short for Objective Difference Grade.

Roughly speaking:

• 0 means the difference is imperceptible
• -1 means perceptible but not annoying
• -2 means slightly annoying
• -3 means annoying
• -4 means very annoying

Again, no objective metric is a substitute for actual listening, and PEAQ is not an ABX test. But it is still extremely useful here, because we are not dealing with tiny differences between already-good encoders. We are dealing with a codec that claims to challenge established formats, and a benchmark that shows whether it can actually do that.

The Leaderboard

Here is the overall leaderboard from the run:

xychart-beta
    title "Mean quality score at nominal 128 kbps"
    x-axis ["qaac", "opus", "lame", "adc"]
    y-axis "score" 0 --> 80
    bar "Quality score" [74.00, 72.90, 69.53, 59.39]

The first thing to notice is that ADC is totally lagging behind. Its mean ODG is -1.576. Contrary to the website's claims, that is not "redefining the DNA of Audio Compression". That phrase alone almost makes me want to laugh, especially with that ODG.

Yes, qaac and opus averaged a few kilobits above the nominal target, but I made it so that the report compensates for that with a bitrate factor, which is why the adjusted scores are listed separately. Even after that penalty, qaac and opus still stay comfortably on top. If you ignore bitrate adjustment entirely and look only at raw quality score, ADC is still last by more than 10 points behind LAME, and by roughly 13 to 15 points behind Opus and qaac. So yeah, this is not a case of "other codecs cheated on bitrate." ADC simply produced worse audio.

ADC Is Not Losing by a Little

If we count track wins, the picture gets even uglier.

xychart-beta
    title "First-place finishes across 24 tracks"
    x-axis ["qaac", "opus", "lame", "adc"]
    y-axis "tracks" 0 --> 24
    bar "Wins" [21, 3, 0, 0]

Like, literally. ADC did not win a single track.

It also finished last on 23 of 24 tracks. The only time it avoided last place was on Chief Keef - Love Sosa, where it barely edged out LAME, and even there it still lost to both Opus and qaac. That is an important distinction. The result here is not "ADC loses to modern codecs but at least it holds its own against MP3." No. It pretty much loses to everything, including an encoder architecture that most people consider to be ancient. And funny enough, MP3 also uses QMF, just like ADC. Geez, I wonder whether there's some correlation between using QMF and losing badly on benchmarks. Hmm.

We can also bucket the ODG results by severity:

pie showData
    title ADC ODG severity distribution
    "Better than -1" : 5
    "-1 to -2" : 14
    "-2 to -3" : 2
    "<= -3" : 3

That means ADC spent most of the benchmark in the region where degradation is not just measurable, but plainly noticeable. And on three tracks, it crossed into "annoying" territory. At 128 kbps. Can you believe that a "modern" and "revolutionary" lossy audio codec to sound "annoying" at 128 kbps? I can't.

The Worst Cases Say A Lot

Here are the five worst ADC results in the run:

These are huge losses. Like, wow.

The two Fearofdark tracks are especially devastating, because they line up almost perfectly with the earlier spectrogram results. The synthetic content, sharp harmonics, and dense upper-band activity are exactly the sort of material that will expose a coarse or unstable coding front end.

The Sergio Mendes & Brasil 66 results are also interesting. These are old bossa nova recordings with extremely wide stereo panning, the kind where instruments can sit almost entirely on the left or right channel with very little in between. That makes them an especially awkward match for a codec that already seems to have stereo-state weirdness. Even ignoring the channel-swap issue for a moment (whoops, foreshadowing ruined), that kind of hard-panned mix is not forgiving.

There is also one detail here that matters a lot: on Rolling Down The Street, In My Katamari, ADC actually used more bitrate than qaac, and more bitrate than Opus by an even wider margin, yet still collapsed to an ODG of -3.018.

That is the key theme of this entire article. The problem is not simply that ADC has fewer bits. The problem is that the bits are not going where the ear needs them to go.

To be fair, and for completeness, ADC's best results were these:

Chief Keef's Love Sosa is a drill / trap track with very crisp hi-hats and snares, so I really would not have expected ADC to edge out LAME there, yet somehow it did. Barely, but still. Dragonforce, on the other hand, is a wall of fast metal arrangement, and The Rite of Spring result is a fragment of Stravinsky orchestral material, so ADC's better-looking outcomes are not confined to one genre. They just still are not actually wins.

Where the Bits Actually Go

Here is a more useful comparison:

LAME gains a very large quality advantage over ADC while spending only about 1.3 kbps more on average. Opus and qaac gain even more quality while still staying in the same rough bitrate neighborhood.

And again, there are individual tracks where ADC spends more than the competing codec and still loses badly:

• Surfing on a Sine Wave: ADC used 7.96 kbps more than Opus and still scored -3.227 vs -0.235
• Rolling Down The Street, In My Katamari: ADC used 1.90 kbps more than qaac and still scored -3.018 vs -0.152
• Belphegor - Baphomet: ADC used 6.48 kbps more than Opus and still scored -1.196 vs -0.524

This is why the "time-domain purity" marketing does not help (if it indeed is purely time-domain, because as soon as we bring QMF into the pipeline, it's no longer purely time-domain). It does not matter how... hmm, I can't even say "modern" since QMF is old as heck, but anyway, if the encoder keeps spending bits on the wrong things and leaving audible damage behind, it's not winning any ODG metric. Ever. Modern codecs are simply better because they know how to distribute limited bitrate according to perception. ADC, at least in my tests, plainly does not. And the developer admits that:

To reiterate for clarity: ADC is a free, experimental, and demonstrative lossy audio codec/archiver. It belongs to the DPCM family, and its current performance and characteristics are inherently shaped by this foundational choice. As such, it operates within certain technical boundaries that differ from codecs based on other principles (like MDCT-based transforms).

Key aspects of its current experimental state include "It does not yet employ psychoacoustic models for inaudible frequency trimming or masking."

Weird. That's not how the homepage describes ADC, though.

The Benchmark Actually Helped ADC

There is another important detail in the results that I have to say: the benchmark had to clean up ADC's messed up output before it could even score it fairly.

The four ADC tracks that needed left-right swap correction were:

• Belphegor - Baphomet
• Sergio Mendes & Brasil 66 - Batucada
• Sergio Mendes & Brasil 66 - The Look Of Love
• The Winstons - Amen Brother

The two Sergio Mendes & Brasil 66 tracks, as mentioned above, are unusually wide-panned stereo recordings, which makes any channel confusion feel even less excusable.

The developer actually tried to pin this on FFmpeg, claiming that it "sometimes inverts the stereo channels when reading metadata."

Warning: In this version, ffmpeg sometimes inverts the stereo channels when reading metadata. In the next version, I will disable metadata processing, at least for ADC.

I do not buy that explanation at all. First, because channel swaps are not some ordinary quirk people just casually expect from FFmpeg, of all things. Heck, this is FFmpeg we're talking about! And second, because I also tested ADC without using FFmpeg nor the ADC converter GUI that depends on FFmpeg. The swap still happened in my tests. At that point, blaming FFmpeg makes me feel like the developer just doesn't have it in their mind that they might have done something wrong (and that ADC is messing things up). It's definitely something else's fault. Yeah, it's definitely FFmpeg--not my perfect, revolutionary, ground-breaking audio codec. Nuh-uh.

This matters because the report did not punish ADC for these issues, be it stereo swapping or random algorithmic delays. (Not to mention the author claims it's zero latency, but... anyway.) The benchmark framework detected them, compensated for them, and only then computed ODG, SNR, and the rest. So if anything, this benchmark is more generous to ADC than a naive measurement would have been. The poor scores are not because the files were misaligned. The files were aligned first, and ADC still ended up far behind.

The "Solo Developer" Defense

At this point, one common defense appears almost automatically:

As a final note, consider this: ADC is developed by a single individual without an audio engineering team, corporate funding, or the decades of research backing MPEG codecs. That it can even be compared to xHE-AAC [...] on any metric is remarkable.

Sure. Writing an audio codec alone is hard. Writing a lossy one is even harder. Doing it without a corporate research lab, formal listening infrastructure, or years of accumulated implementation experience is harder still. There is nothing embarrassing about building an experimental codec that falls short of AAC, Opus, or even MP3. Most experiments will.

But that is exactly why the marketing matters. If ADC had been presented as a personal experiment, a learning project, or an unconventional prototype, then "it was made by one person" would be perfectly fair context. In that framing, merely getting a working encoder and decoder would already be interesting.

The problem is that this is not how ADC was presented. It was presented as:

• a major leap in audio coding
• a challenge to transform codecs
• something "competitive" with established industry standards
• and a rethink of what lossy audio compression should be doing

Once you make claims at that level, the standard changes. You are no longer asking to be judged as a hobby project. You are asking to be judged as an actual serious industry-standard codec. And when judged that way, the benchmark result is still the benchmark result.

Being written by one person does not make an ODG of -3.227 on tracker material more acceptable. It does not make channel swaps acceptable. It does not make ADC's 23 last-place finishes acceptable. It does not transform "worse than LAME most of the time" into "competitive with AAC." That does not explain anything.

So yes, as a solo effort, ADC is ambitious. Extremely ambitious. But its claims about codec performance still do not hold up.

What About The Teased v0.85?

And that brings us to the obvious follow-up question: what about the unreleased v0.85 that the developer is already teasing?

The description promises a refined "dual-predictor architecture", sharper transient response, "excellent/transparent" quality at 130-134 kbps, lower CPU and RAM use, 0.18 ms latency, stable seeking even past 120 minutes, and a step closer to what the developer calls "mathematical transparency".

Now, to be fair, unreleased versions are allowed to improve. They should improve. If v0.85 really does fix some of the problems seen in v0.84 rev.0, then good. That would be the normal and healthy thing for an experimental codec to do. But taken in the context of this entire series, let's be honest. The teaser reads less like evidence and more like the same pattern continuing.

First, the framing is still confused in the exact same way. Phrases like "treating audio as a continuous wave rather than a set of frequency bins" (wait, I thought ADC was purely time-domain? Hmm...) and "without the pre-echo smear typical of MDCT-based codecs" are not neutral technical descriptions. They repeat the same old rhetorical move from the earlier ADC pages: define transform codecs as inherently flawed, then present ADC as philosophically pure for avoiding those flaws. But as we already established in the earlier articles, MDCT itself is not the thing that causes pre-echo, and "continuous wave" wording does not magically prove superior coding efficiency. So basically, ADC is throwing the "flawed" MDCT away, just so it can use another flawed approach.

Second, the quality claim is huge. At roughly this same bitrate class, v0.84 rev.0 did not merely fall a little short. It finished last on 23 of 24 tracks in my benchmark, with a mean ODG of -1.576. So if v0.85 is now being described as reaching "excellent" or even "transparent" quality at 130-134 kbps, that would represent an enormous jump, not a small iterative refinement. Extraordinary improvements can happen, sure. But as they say, extraordinary claims need need extraordinary proof: fresh benchmarks, listening tests, files, reproducible methodology, and comparison against current encoders, not just adjectives in a teaser paragraph.

Third, some of the other claims sound less like breakthroughs and more like ADC trying to finish solving problems it already claimed to have solved. "Ultra-stable search" and the renewed low-latency story would certainly be welcome, but those are also precisely the areas where previous ADC releases made sweeping promises that did not survive inspection. Less talk, more executables. I guess.

And finally, "mathematical transparency" is still a very strange phrase for a lossy codec. A lossy codec can aim for perceptual transparency. It can aim for better artifact control, or better efficiency. But once a codec quantizes and throws information away, "digital integrity" and "mathematical transparency" stop being literal properties and start becoming marketing language again.

So my position on v0.85 is simple: maybe it will be better. I genuinely hope it is. But until there is a public build that can be tested, compared, listened to, and inspected, v0.85 is just more of the same set of claims.

Roadmap

This article is the fourth of a series of articles focused on debunking ADC and its claims.

Article map

The following articles will be published over time. They will become links as each article is published.

1. Revolutionary Codec or Overhyped Experiment?
2. "Audio DNA" and Other Things that Mean Nothing
3. Inside ADC: A Deep Analysis of the Codec
4. The Spectrograms Don't Lie: ODG and Where the Bits Actually Go <- you are here
5. Bonus: The SIC Image Codec and the Same Pattern of Overclaiming

A Final Note For The Main ADC Series

Whew. This was long. If there is one conclusion that ties these four main ADC articles together, it is this: the spectrograms were not lying, and neither were the benchmarks.

Across the series, the pattern stayed remarkably consistent. The homepage language was confused. The anti-MDCT framing was technically shaky. The internal design turned out to be much more ordinary, coarse, and fragile than the marketing suggested. And when the codec was finally put in a proper benchmark at roughly the bitrate where it is now teased as becoming "transparent", it was not competitive with Opus, AAC, or even, almost all of the time, MP3.

That, to me, is the real conclusion of the series.

This was never about saying that experiments are bad, or that solo developers should not try weird codec ideas. Heck, I do lots of experiments as well, and I'm a solo developer. Quite the opposite, actually. Experiments are good. Weird ideas are good. Personal research projects are good. But if you want to present an experiment as a revolution, then you inherit the burden of proof that comes with revolutionary claims.

If a future v0.85 or v0.90 genuinely improves ADC, then that is fine. Better yet, that would be interesting. But future improvements do not retroactively validate old claims, and they do not erase old results. Each version still has to stand on what it can actually demonstrate. Am I optimistic, though? Meh. I dunno. After all this, who would be?

In the end, we can now answer the title of the first article: ADC is an overhyped experimental codec that kept promising more than it could show.