ADC Audio Codec: Time-Domain Prediction via QMF Subbands

[Nania Francesco]

On this aspect I think I have improved a lot with the new version, the fact is that I don't have much experience with advanced VBR management and currently I use a fairly responsive but certainly not advanced code like the other codecs developed for years, plus another important detail is the fact of signal hysteresis (which in other codecs I don't know how it is managed). In short, if I quickly change the bitrate the coefficients interfere with the 8-subband QMF filter which works with double factors (si double not int32_t) so that every single fluctuation has a sharp impact on the final result.

When I release the open code anyone who wants can help me get results even 10-15% higher!

[Nania Francesco]

ADC (Advanced Domain Audio Codec) v0.84 Rev 0 Released.

I am pleased to announce the release of ADC v0.84 Revision 0. This version represents a significant milestone in the development of the Advanced Domain Audio Codec, pushing the boundaries of subband predictive coding further than ever before.The Peak of Closed-Source DevelopmentThis release is likely to be the final closed-source iteration of the ADC engine. After years of private research and community-driven feedback, the core architecture—centered around our unique PID-controlled QMF bank—has reached a level of stability and transparency that warrants a transition to a new development model.Key Improvements in v0.84 .
What’s Next?As we look toward the future, the project is preparing to transition to an Open Source model (GPLv3) on GitHub.

link:

http://heartofcomp.altervista.org/ADCodec.htm

Sweep source : https://encode.su/attachment.php?att...8&d=1769807880

Sweep test 22hz to 22 khz ADC (53 kbps) : https://encode.su/attachment.php?att...5&d=1769807323

Sweep test 22hz to 22 khz MP4 (>53kbps) : https://encode.su/attachment.php?att...6&d=1769807488

samples download: https://encode.su/attachment.php?att...7&d=1769807579

[GeoffreyA]

Originally Posted by Nania Francesco

Excellent observations. You are correct, transparency at 128 kbps is not new. ADC's goal is to verify whether time domain prediction can offer unique advantages, such as instantaneous random access, while ensuring competitive quality.

As for lower bitrates: at 84 kbps, ADC maintains a bandwidth of ~20 kHz where AAC struggles greatly (-3.1 ODG vs. -1.6), albeit with higher background noise: an interesting trade-off worth investigating.

The 100-generation test is indeed a pathological case that goes beyond practical use, but resistance to generation loss is a valid area of research. The project is in its early stages; current results show that it is approaching basic competitiveness with several architectural compromises.

All constructive feedback on improving low bitrate performance is welcome, as development will continue in the future on GitHub.

It is useful to stress the codec with lower bitrates, such as ~64 kbps, in order to bring out its characteristic artefacts. Tackling those will help all bitrates. Goku trained at 100x Earth's normal gravity, and was then ready for Frieza!

ADC opts for a full-bandwidth approach like Opus; but cutting off higher frequencies, as bitrates drop, is always helpful when it comes to lossy, perceptual encoding, taking bits from those parts we are less sensitive to. During development, though, it might be useful first to tackle the artefacts with other techniques, then on top of that, add the low-passing.

I noticed that ADC's characteristic artefacts are analogue-like noise, whereas others, such as Opus, grow garbled and distorted. So, I would say ADC is on a firmer footing and has the potential to outclass the others with time and tuning. Would dithering and noise-shaping curves help?

Originally Posted by Nania Francesco

On this aspect I think I have improved a lot with the new version, the fact is that I don't have much experience with advanced VBR management and currently I use a fairly responsive but certainly not advanced code like the other codecs developed for years, plus another important detail is the fact of signal hysteresis (which in other codecs I don't know how it is managed). In short, if I quickly change the bitrate the coefficients interfere with the 8-subband QMF filter which works with double factors (si double not int32_t) so that every single fluctuation has a sharp impact on the final result.

When I release the open code anyone who wants can help me get results even 10-15% higher!

VBR can take a long time to perfect. Looking back at LAME, the --vbr-new algorithm was experimental for ages before replacing the old one. In video codecs, some contemporary encoders still have rate-control issues.

[Nania Francesco]

Hi GeoffreyA,

Thank you so much for your insights. I sincerely appreciate that a user with your experience has grasped the unique nature of ADC artifacts: that "analog" quality that clearly distinguishes it from the digital distortion typical of transformative codecs like Opus or AAC. It's precisely this structural solidity that I intend to build the future of the project on.

You've hit the nail on the head about "gravity 100": training the ADC to maintain the entire bandwidth at critical bitrates is a deliberate choice. While it may initially seem punitive, it serves to highlight the predictor's limitations and then address them at the root, rather than hiding them under premature frequency clipping. However, I agree that introducing an adaptive low-pass filter and implementing noise shaping and dithering curves are the next logical steps to eliminate residual artifacts at 64 kbps.

Regarding VBR management and signal hysteresis in the QMF filter, I admit it's a complex challenge. I'm currently working to minimize the impact of bitrate fluctuations on the coefficients, trying to make the transition between different quantization intensities as smooth as possible, avoiding "jumps" in the time domain.

Thank you for your constructive feedback and for following the development so far. You can bet: the refinement work is just beginning, and there's still plenty of room for improvement. I can't wait to show what the ADC will be capable of with future predictor tuning.

Maybe you don't care much but I managed to launch 35 songs at the same time and the 7940hs amd CPU was consuming 25%, the browser slowed down a little but the sound was smooth. I'm not kidding, I think ADC works perfectly even on a watch with a CPU.

See you soon on GitHub for open source!

[Nania Francesco]

While waiting for the next version which will significantly improve the quality, I will show you how to set foobar2000 to launch .adc files, while waiting for a specific plugin.

https://www.foobar2000.org/getcompon...fb2k-component

https://encode.su/attachment.php?att...0&d=1770034049

Or how do I do it by pointing the .adc file, right-clicking on run_adc.bat, and applying the changes. It will launch instantly.

https://encode.su/attachment.php?att...2&d=1770034178

[GeoffreyA]

That's the right approach: tackle the root with full visibility, and once that's mitigated with the correct solution, add the low-passing, noise shaping, etc. Perhaps such quality tools can be added as an option, and when the encoder is ready for production, turned on.

Decoding complexity is important, especially in power- or CPU-constrained environments. So if that's working all right, another positive.

I'd like to contribute on Github, but unfortunately, I don't understand the intricacies of developing an audio encoder as yourself. I admit it's fascinating, though, and wish I had studied these things.

[Nania Francesco]

Thank you so much for your kind words of appreciation and for following the project with such critical attention. You've nailed it: simplicity is a strength, not a limitation.

On your contribution: Don't underestimate yourself. Developing a codec isn't just advanced mathematics. There are many ways you can contribute:

Real-world testing - Try it on different hardware (Raspberry Pi, older smartphones, etc.) and on various content (podcasts, music, audiobooks) to evaluate its robustness.

Documentation - Explain how it works clearly (something I struggle to do, immersed in the technical details).

Practical benchmarks - Subjective A/B/X comparisons against other codecs, which are often more meaningful than objective tests.

Code optimization - Even without understanding the theory, you can improve efficiency, readability, and portability.

On the project philosophy: You're describing the roadmap exactly. First, the solid foundation (QMF + stable predictors), then the psychacoustic optimizations. It's like building an engine: first it has to work reliably, then you can optimize it for performance or efficiency.

[Nania Francesco]

ADC GUI Demo Released - Free Converter Tool

Now available: A free GUI for encoding/decoding ADC audio files.
Convert between ADC and common formats (MP3, WAV, FLAC) with batch processing.
Includes both native ADC compression and FFmpeg-powered conversion.

Demo download page :http://heartofcomp.altervista.org/ADCodec.htm
Requirements: Place ffmpeg.exe in same folder as the tool. https://github.com/BtbN/FFmpeg-Builds/releases
Perfect for testing ADC codec capabilities.

[GeoffreyA]

Originally Posted by Nania Francesco

Thank you so much for your kind words of appreciation and for following the project with such critical attention. You've nailed it: simplicity is a strength, not a limitation.

On your contribution: Don't underestimate yourself. Developing a codec isn't just advanced mathematics. There are many ways you can contribute:

Real-world testing - Try it on different hardware (Raspberry Pi, older smartphones, etc.) and on various content (podcasts, music, audiobooks) to evaluate its robustness.

Documentation - Explain how it works clearly (something I struggle to do, immersed in the technical details).

Practical benchmarks - Subjective A/B/X comparisons against other codecs, which are often more meaningful than objective tests.

Code optimization - Even without understanding the theory, you can improve efficiency, readability, and portability.

On the project philosophy: You're describing the roadmap exactly. First, the solid foundation (QMF + stable predictors), then the psychacoustic optimizations. It's like building an engine: first it has to work reliably, then you can optimize it for performance or efficiency.

Thanks for the encouragement. And yes, there are many ways one can contribute to the success of a project.

[Nania Francesco]

Hi everyone, I wanted to share some major updates on my audio codec, ADC.
After extensive work, I’ve completely overhauled the engine. It has evolved from a single-band design into a sophisticated 8-subband QMF architecture. I’ve spent the last few months refining the dual-prediction logic and the range coder, and based on my latest technical analysis and intensive ABX listening tests, this new version is a massive leap forward in transparency. I’ve reached a point where I feel the algorithm has matured into something truly valuable. Because of the effort and the unique IP involved, I’ve decided that if I move to GitHub, it will likely be as an SDK with static libraries (.a) rather than an open-source project. I want to keep the core source closed for now, as it represents two years of constant evolution and personal investment.

I'm focused on providing a high-performance tool for the community that avoids the typical artifacts of transform-based codecs. I’d be happy to hear your thoughts on this direction or any technical requirements you’d like to see in a potential SDK

[GeoffreyA]

It's entirely up to you if you'd prefer to keep the source closed, Nania. You've invested time and effort, and that's understandable.

An SDK, preferably with a simple interface, will be necessary for the project in the long term so that other software can use it; for example, audio applications and encoders. You'll have to find the best licence that squares with a closed-source, static library scenario. Applications might want to use a DLL also.

[Nania Francesco]

ADC Codec v0.85
The upcoming 0.85 release will refine our unique dual-predictor architecture, treating audio as a continuous wave rather than a set of frequency bins. Improved temporal coherence: The transient response is now sharper than ever. Snare drum hits and string pluckings retain their original “bite” without the pre-echo smear typical of MDCT-based codecs.
Efficiency milestone: We are reaching “excellent/transparent” levels at 130-134 kbps, exceeding modern standards and using significantly less CPU and RAM.
The advantage of “zero latency”: We have maintained latency of 0.18 ms. It's not just fast, it's instantaneous.
Ultra-stable search: Instant access even to files over 120 minutes long without popping or glitching.
ADC does not try to “trick” the brain, but is designed to preserve the digital integrity of the signal. Whether it's a high-end desktop chain or a mobile IoT device, version 0.85 brings us one step closer to the goal: mathematical transparency.

[Nania Francesco]

DC Ecosystem Update: Release of Converter GUI 4.0 (New Features and Multilingual Support)

As development continues on the highly anticipated ADC 0.85 engine, I am pleased to announce the official release of ADC Converter 4.0. This major GUI update greatly simplifies the workflow for encoding and decoding the Advanced Domain Codec format.
Key features of this release include:
Full multilingual support: the interface is now available in English, Italian, Spanish, German, and Chinese.
Improved format compatibility: seamless conversion from various audio formats to ADC and vice versa, thanks to the integrated FFmpeg LGPL engine (now included in the package for a plug-and-play experience).
Improved batch processing: a clearer, highly visible GUI designed for stable recursive processing of entire music libraries.
Transparency: please note that this is still a free demo version intended to test the unique transient integrity and low-latency capabilities of the ADC algorithm.
Stay tuned for further updates as we approach the release of engine 0.85. Your feedback on the new GUI is greatly appreciated!

download page :https://heartofcomp.altervista.org/ADCodec.htm

[j7n]

The demo clip on the website is easy to ABX. You are using a lossy source, which is usually not done. When listening loudly I can hear the treble coming in steps during the fade-in. I then reduced the volume to medium-low because it is midnight and focused on sharp clicks such as the one at 25.5 second mark. They are less distinct, more like a puff with an echo. Not annoying. The low dynamic range threshold could be picked out in a quiet room.

foo_abx 2.2.3 report
foobar2000 v2.24.3
2026-02-16 00:15:01

File A: source1.wav
SHA1: b2c5a6c5ed317a48740dc4d7453ca02848ae3a26
File B: source1adc.wav
SHA1: 2b51e1fa3b7e01eff23ecdd9fb876eac1de08279

Output:
ASIO : E-MU ASIO
Crossfading: NO

00:15:01 : Test started.
00:15:42 : Test restarted.
00:15:42 : 01/01
00:15:53 : Test restarted.
00:15:53 : 02/02
00:15:59 : Test restarted.
00:15:59 : 03/03
00:16:34 : Test restarted.
00:16:34 : 04/04
00:16:54 : Test restarted.
00:16:54 : 05/05
00:17:19 : Test restarted.
00:17:19 : 06/06
00:17:35 : Test restarted.
00:17:35 : 07/07
00:17:52 : Test restarted.
00:17:52 : 08/08
00:18:07 : Test restarted.
00:18:07 : 09/09
00:18:30 : Test restarted.
00:18:30 : 10/10
00:18:53 : Test restarted.
00:18:53 : 11/11
00:19:17 : Test restarted.
00:19:17 : 12/12
00:19:41 : Test restarted.
00:19:41 : 13/13
00:19:55 : Test restarted.
00:19:55 : 14/14
00:20:17 : Test restarted.
00:20:17 : 15/15
00:20:27 : Test restarted.
00:20:27 : 16/16
00:20:27 : Test finished.

 ---------- 
Total: 16/16
p-value: 0 (0%)

 -- signature -- 
c74264aea7c912c6e84b262de3196c6d2c51f803

I have a suspicion that "Equinoxe Part 3" might not be handled well by this codec. But I was unable to run ADC_generic.exe nor ADC_amd.exe on my Windows 2008 R2 computer, and not wanting to boot another computer with Windows 10 to try.

[Nania Francesco]

Equinoxe part 3 is one of the files I use to test the codec. The mathematical results (peaq values) for standard MP4 give this result at approximately 128 kbps Processing of the file converted from CD
BandwidthRefB: 918.68
BandwidthTestB: 674.034
Total NMRB: -7.34133
WinModDiff1B: 13.3779
ADBB: 1.45261
EHSB: 1.03738
AvgModDiff1B: 13.2378
AvgModDiff2B: 29.2545
RmsNoiseLoudB: 0.265861
MFPDB: 1
RelDistFramesB: 0.924735
Distortion Index: 0.191
Objective Difference Grade: -1.680

Regarding the upcoming version of ADC to be released shortly (0.85) I get the same bitrate:

BandwidthRefB: 863.746
BandwidthTestB: 862.211
Total NMRB: -4.88181
WinModDiff1B: 16.0846
ADBB: 1.72422
EHSB: 0.542458
AvgModDiff1B: 15.6735
AvgModDiff2B: 33.3566
RmsNoiseLoudB: 0.433674
MFPDB: 1
RelDistFramesB: 0.909003
Distortion Index: 0.316
Objective Difference Grade: -1.551,

things change on an mp3 source and are reversed, and mp4 becomes superior. Perhaps you used an encoded source?

I understand purists, but ABX tests are revealing yet always subjective and, in my opinion, not scientifically adequate except for detecting loud noises and strong crackling that are not present in the original. ADC does not operate in the field of psychoacoustics and does not remove inaudible frequencies or frequencies according to parameters that cut sounds and harmonics.

I confirm that this track is to be considered a killer sample for all codecs.

I would like to take this opportunity to announce that I will soon be releasing a version of the GUI that allows you to convert to various formats without relying solely on ADC (which is a supported codec), browse folders in Explorer style, and launch playback, including ADC.

[j7n]

I downloaded the preview files from the HeartOfComp website, and couldn't encode anything myself because my PC is too old for ADC. If the bitrate was 128, then it is not bad.

I recognize elements of "psychoacoustics". You have 8 frequency bands, an absolute threshold of hearing (ath) for each, the top bands are quantized more like in other codecs, there is effective "post-masking" after sharp percussion hits. Maybe these dropouts are what I hear as the clicks becoming softer.

source: https://imgbox.com/qAtd88yW
encoded: https://imgbox.com/dJPoTlre

In constant bitrate that uses 128 or whatever kbits for every unit of time, it should not have these steps in quiet. It should adapt and code the low level. Making VBR is tougher, then you have to decide what level is effectively silence. The Musepack codec received criticism for its strict VBR in quiet classical music.