ADC Audio Codec: Time-Domain Prediction via QMF Subbands

[Nania Francesco]

Hello everyone,

It is a true honor for me to finally post here in the audio section. I have been a devoted admirer and follower of Doom9 since its very inception, and I consider this community the benchmark for high-level multimedia discussion.

I would like to share the current progress of a project I am developing: ADC, an experimental audio codec. While still a work in progress, I believe it has reached a level of development that might interest this community for testing and technical feedback.

Technical Overview: ADC is built on a hybrid architecture that seeks to balance temporal precision with spectral efficiency:

Subband Decomposition: The signal is split using an efficient 8-subband Quadrature Mirror Filter (QMF) bank.

Predictive Coding: Instead of traditional frequency-domain transforms (like MDCT), ADC operates in the time domain. It utilizes highly optimized predictors to derive coefficients that model the signal's redundancy.

Entropy Coding: A high-performance Range Coder is used for the final bitstream compression.

Philosophy and Current Results: My goal with ADC is to achieve high-fidelity results without relying on artificial reconstruction techniques like SBR. By focusing on "extreme prediction" mathematics, the codec aims to preserve real spectral components and maintain high temporal stability, which is particularly beneficial for complex transients and reverberant fields.

Initial PEAQ (ITU-R BS.1387) benchmarks for the current online version are encouraging:

ODG: Approximately -1.1 at 128 kbps (Stereo, 48kHz).

Objective: Maintaining a natural bandwidth and structural integrity without typical transform-coding artifacts.

I am well aware that there is always room for improvement, and I am humbled to be among such expert developers and enthusiasts. I plan to provide binary executables and a more detailed technical overview via Zenodo (with a registered DOI https://zenodo.org/records/18263352) in the coming days to allow for independent evaluation.

I look forward to any technical insights or suggestions you might have.

Best regards, Francesco

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

[GeoffreyA]

Congratulations on building the new audio codec.

I did some quick testing. At a target of -v96, giving a bitrate of 112 kbps, I heard changes in the stereo image and distortion in the lyrics: a sort of noisiness, and perhaps, I am not certain, MP3-like artefacts. Apple QAAC encodings are included for comparison.

https://workupload.com/file/YgKPKVpg8Sy

[Nania Francesco]

Thank you very much for your feedback and for taking the time to conduct these tests.
I truly appreciate the comparison with Apple's QAAC, which is undoubtedly one of the gold standards in the industry.
Regarding your observations: the 'noisiness' and the impact on the stereo image you noticed in the lyrics are exactly the areas I have been focusing on in the most recent development cycles. The version you tested is an early build, and I am pleased to share that the current internal iteration has already made significant leaps in stability and noise management (NMR).
In my latest stress tests across 66 diverse tracks (including several 'killer samples'), the current engine demonstrates much higher coherence. Here is a brief look at the latest mean results at ~128 kbps:
Average ODG: -0.726 (Stable across complex transients)
BandwidthTestB: 839.07 (Maintaining significant real high-frequency content)
Distortion Index: 1.287
The 'MP3-like' artifacts you mentioned are likely related to the initial tuning of the time-domain predictors in the higher subbands. I am currently refining the coupling between the QMF banks and the Range Coder to improve the reconstruction of the stereo field and eliminate that specific noise floor.
I am working on a much more efficient and stable release, which I plan to publish soon on Zenodo with a full technical White Paper.
Your samples are invaluable for my tuning process—thank you again for your contribution to the development of ADC.

[GeoffreyA]

You're welcome; I wish you luck. A great encoder gets there through endless tuning, LAME being a fine example. I don't understand the intricacies of audio encoders, but would think that noise masking and shaping might help these artefacts.

Does it use a psychoacoustic model?

[Nania Francesco]

Thanks for the encouragement! You're absolutely right: LAME's story proves that fine-tuning is a long but rewarding journey.

Regarding your question about the Psychoacoustic Model: Currently, ADC relies more on an advanced predictive mathematical model in the time domain than on a traditional psychoacoustic masking system. At this stage of development, the codec was designed primarily for higher bitrates, where the priority is to preserve the structural integrity of the original waveform and the entire spectral bandwidth.

112-128 kbps is a very challenging "stress zone" for any non-SBR codec, but I am committed to improving its performance even at these lower bitrates.

Future Roadmap and Robustness: One of my long-term goals is to ensure that the codec remains robust even after multiple recoding cycles. While lossy formats are known to degrade at every step, I am working toward a goal where ADC can maintain acceptable quality even after 20 generations of recoding, which poses a significant challenge for predictive models.

Psychoacoustic Integration: I fully agree that noise masking and modeling are the next frontiers of ADC. In future releases —especially if I decide to open the source code to the community—, implementing a sophisticated psychoacoustic model will be a top priority. Combining the current "extreme prediction" with advanced masking will likely eliminate the artifacts you've heard.

Thanks for your insights; they're helping me define the roadmap for future releases!

[Nania Francesco]

I wanted to replicate your test just to be sure. I don't know where you found the sample you posted, but I have the original sample on CD and I tested the exact tempo you posted, but the results are anomalous. I don't know how you may have introduced strong noising, perhaps unintentionally. My results are these real ones.
Resulting ODG: -0.80
Resulting DIX: 1.14

BandwidthRef 20871.2713
BandwidthTest 18980.0380
NMR -8.2527
WinModDiff1 11.0275
ADB 1.4840
EHS 0.2553
AvgModDiff1 9.9723
AvgModDiff2 13.1076
NoiseLoud 0.4593
MFPD 1.0000
RDF 0.4604

while the results of the ref.wav you posted to me are

Resulting ODG: -3.55
Resulting DIX: -2.16

BandwidthRef 20331.5122
BandwidthTest 18655.7646
NMR 0.4074
WinModDiff1 33.8316
ADB 2.4965
EHS 0.2747
AvgModDiff1 29.4510
AvgModDiff2 43.2592
NoiseLoud 6.5280
MFPD 1.0000
RDF 0.8442

I'm sure you didn't do this to belittle my codec.

These are the results with Exhale mp4 option 4 that you can test too (110 kbps) .

Resulting ODG: -3.90
Resulting DIX: -4.00

BandwidthRef 19346.3475
BandwidthTest 17496.6673
NMR 31.8837
WinModDiff1 144.8832
ADB 3.3051
EHS 0.7682
AvgModDiff1 100.1006
AvgModDiff2 187.6794
NoiseLoud 22.7027
MFPD 1.0000
RDF 1.0000

I've probably tested the song you posted at least a thousand times, and the sound seemed really strange. Thanks anyway.

[GeoffreyA]

I assure you the test was done in good faith. I had that sample stored as FLAC, and before encoding, converted it to 16-bit WAV with FFmpeg. Actually, last year, another member found that the sample had DC shift, which caused problems with Opus on repeated encoding.

https://forum.doom9.org/showthread.php?p=2022678#post2022678

I'll try some other songs and see if the results are similar, and post that FLAC, too, for you to test.

[Nania Francesco]

I assure you the test was done in good faith. I had that sample stored as FLAC, and before encoding, converted it to 16-bit WAV with FFmpeg. Actually, last year, another member found that the sample had DC shift, which caused problems with Opus on repeated encoding.

https://forum.doom9.org/showthread.php?p=2022678#post2022678

I'll try some other songs and see if the results are similar, and post that FLAC, too, for you to test.
Hi GeoffreyA, thank you for the clarification. The DC shift issue explains the massive discrepancy in the PEAQ results and the artifacts you heard. It’s a very interesting 'stress test' case!

It is actually quite remarkable to see how the time-domain predictive model in ADC handled the corrupted sample compared to transform-based codecs; maintaining an ODG of -3.55 vs the -3.90 of other implementations on the same file shows a surprising level of structural resilience.

I would be very happy to test the FLAC versions you mentioned. This kind of high-quality peer feedback is exactly what helps in fine-tuning the 8-subband QMF integration. Looking forward to your next samples

[GeoffreyA]

After a bit of digging, I found the problem. That sample is supposed to come from the Japanese 1st-pressing CD, the famous 35.8P version, and had pre-emphasis applied. (I disclose I downloaded this.) The ripped track had not reversed the pre-emphasis; hence, the shrill, treble, tin-can sound. Your ears were right that something was amiss. Using SOX to de-emphasise the clip,

sox REF.flac -b 24 out.wav deemph

it sounded normal, as Billie Jean should and comparison against a later version confirmed.

Now, re-encoding the files using the de-emphasised source, ADC sounds roughly transparent to my ears. The noisiness is gone, along with the changes to the stereo image. So the encoder is working well, and the previous results are due to my error. However, even though the old clip was pathological, it still brings out areas that ADC could improve on. Too much high-frequency material gives it trouble, suggesting that a low-pass filter would help. Notice that QAAC fared much better on the old, high-pitched sample.

So, my apologies, Nania. It was not intentional on my part to make your encoder look bad, but the consequence of choosing, innocently, a sort of "killer" clip (though good as a stress test).

https://workupload.com/file/RNDFG5h4uSN

https://i.imgur.com/uEkevPT.png
https://i.imgur.com/6BeACXT.png

Taking a look at the new encodings above, ADC is keeping frequencies above 20 kHz, whereas Apple is cutting off at 16 kHz or so (it varies with bitrate). So perhaps, ADC could dynamically lower the cutoff as bitrate drops.

Later, I'll test the encoder on my Enya Paint the Sky with Stars CD; her music has a lot of unconventional, varying dynamics and is sometimes high pitched.

[Kurt.noise]

I look forward to any technical insights or suggestions you might have.
Looks like you wrote your message with a translator or an AI prompt...

Please provide a decent decoder not an obscur command line tool.

And btw no one care about PEAQ or ODG stuff around here.

[Nania Francesco]

GeoffreyA,

Thank you for the update and for identifying the cause of the problem. I really appreciate your honesty in acknowledging this and sharing the correction. This approach earns my total respect. I'm preparing a new release that incorporates several stability improvements already developed in-house. I will continue to keep the community updated on progress.

Thank you again for your time and expertise in this test.

[Nania Francesco]

Looks like you wrote your message with a translator or an AI prompt...

Please provide a decent decoder not an obscur command line tool.

And btw no one care about PEAQ or ODG stuff around here.

The codec source code is entirely written in C/C++ by me, as is the initial post. If any expression is unnatural, it is because English is not my native language and I use a translator, but the technical content is authentic. Regarding the decoder, the command line tool is the first functional implementation, necessary for testing and validation. I understand that a more accessible UI would be preferable for general testing, and I'm working on a standalone library and a minimal frontend. On PEAQ metrics: I understand that for many, the listening test is primary. I included the objective data because it provides a repeatable reference point during development. Listenable results, as confirmed by GeoffreyA after fixing the test file, are the ultimate goal.

Please forgive me but I have a minimal knowledge of English that I didn't study in school , unfortunately only French.

I'm not allowed to use Italian, which would be much simpler for me but complex for you.

[Z2697]

I assure you the test was done in good faith. I had that sample stored as FLAC, and before encoding, converted it to 16-bit WAV with FFmpeg. Actually, last year, another member found that the sample had DC shift, which caused problems with Opus on repeated encoding.

https://forum.doom9.org/showthread.php?p=2022678#post2022678

I'll try some other songs and see if the results are similar, and post that FLAC, too, for you to test.

To be clear, I didn't say any sample has DC shift, the problem there is the repeatedly applied dc_reject filter, regardless of the initial sample has DC shift or not.
And that's not a problem, even if it has, the first cycle would be enough to remove it.
The filter itself is indeed quite good and effective, only problem is repeating -- we only need it once at most.

Does that sample have DC shift? I don't think so.
I think at least 95% of the "commercial grade" audio won't have.

[GeoffreyA]

My memory was hazy. Goes to show how our brains blur things together.

Did they fix the issue?

[Z2697]

Did they fix the issue?

Nope... https://github.com/xiph/opus/issues/434
Apparently they think it's OK. (I might have to disagree)

But the new QEXT feature effectively disables that filter, whether it's intentional or not.
But no easily accessable encoder was availbale. (perhaps still is)
I have (https://github.com/Mr-Z-2697/opus) some (https://github.com/Mr-Z-2697/libopusenc) forks (https://github.com/Mr-Z-2697/opus-tools) now... but didn't figure out how to do 96 khz... the extended bitrate and cutoff does work though.

This is too off topic now, maybe we should continue elsewhere if we want.

[Nania Francesco]

Hello everyone, I've updated the web page, freshening it up a bit and making it more user-friendly. You can test the audio of the upcoming version 0.84 rev. 0, which I'm working on and improving. See you soon!

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

[Nania Francesco]

The new version 0.84 is in the final stage, I saw that not everyone appreciates the peaq data (which is a development tool and not an audio qualification tool, obviously not 100% reliable). I show you an ABX test performed on the test downloadable from the Opus site (the famous one with the seven audio clips). With my next ADC 0.84 rev.0 at 160 kbps

codec version I obtained :
foo_abx 2.2.3 report
foobar2000 v2.26 preview 2026-01-15
2026-01-29 19:38:48

File A: orig_opus.wav
SHA1: 70789b7ddefe625270626f6b1b7205fa5cce9728
File B: output.wav
SHA1: 562c1c5f1ec510677228f8fc581d6238dbeec869

Output:
Default : Primary Sound Driver
Crossfading: YES

19:38:48 : Test started.
19:40:05 : Test restarted.
19:40:05 : 01/01
19:40:18 : Test restarted.
19:40:18 : 01/02
19:40:36 : Test restarted.
19:40:36 : 01/03
19:40:57 : Test restarted.
19:40:57 : 01/04
19:41:12 : Test restarted.
19:41:12 : 02/05
19:41:26 : Test restarted.
19:41:26 : 03/06
19:41:50 : Test restarted.
19:41:50 : 04/07
19:42:06 : Test restarted.
19:42:06 : 05/08
19:42:06 : Test finished.

----------
Total: 5/8
p-value: 0.3633 (36.33%)

-- signature --
e320f7c3d3125629c263d59bc5f95ac5d0b8b05f
I barely achieved a similar result with the current codec v.083 rev.1 at 196 kbps.

[VoodooFX]

With my next ADC 0.84 rev.0 at 160 kbps.

Your test shows that it's transparent for you. This was already achieved 25 years ago. Modern codecs can do this at <128 kbps, you may want to test at lower bitrates.

What about the claims at HA, that quality degrades overtime?

[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.

[VoodooFX]

What about the claims at HA, that quality degrades overtime?

I meant that encode starts with high quality and ends with low quality.

[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?attachmentid=13138&d=1769807880

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

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

samples download: https://encode.su/attachment.php?attachmentid=13137&d=1769807579

[GeoffreyA]

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?

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/getcomponent/91c7d38a41095e34b0c0bddf0c0415c3/foo_input_exe.fb2k-component

https://encode.su/attachment.php?attachmentid=13140&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?attachmentid=13142&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]

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.

[GeoffreyA]

Nania, I tried the GUI, and here are my thoughts.

It is simple and easy to use, making conversion more accessible for many. (Personally, I prefer CLI tools.)

It is big and visible; everything is clear.

I noticed that when selecting "FIXED (-q)," the slider beneath doesn't change. Is that a bug?

The next step would be a static library so that players can process ADC. It would be useful in FFmpeg, too, and once there, it would propagate far and wide, but I'm not sure if their licensing model would allow a closed-source library. Perhaps the decoder could be open source but the encoder closed, so as to protect your IP?