Audio Fake Detector PRO

[Redacted]

The disk files for reviewers are the same ones that are sold on platforms and the same ones used for CDs. It's not a destructive marking like the one on films sent to reviewers or Oscar or Cesar voters.

Interesting.

You seem to be implying that if you rip CDs (as I do), you will pick up watermarking data in the resulting FLAC files, yes?

I'm now going to see if I can dig up some tech info on this! I am actually that sad.

 

[Alessandro Comito]

The large and magnificent Neumann capsules drop off above 20 kHz, and the Schoeps Collette series stops at 28 kHz - unless you use a special preamp that can push it up to 40 kHz. But I've never seen anything other than standard models used for recording classical music: neither on the radio nor in the recording sessions I've attended at both large and small labels.

And then there's another problem: what tweeter delivers decent output at a distance of 2 or 3 meters for home listening? Most are very effective low-pass filters.
I'm not saying anything bad about your tool, because catching unscrupulous labels seems like an excellent thing to me. As does making it clear to the public that they are the ones cheating when necessary.

You make excellent points, and they're technically accurate. Neumann large-diaphragm capsules do roll off above 20 kHz, and even the Schoeps Colette series - one of the finest small-diaphragm designs available - reaches 28 kHz only under ideal conditions with specialised preamps that almost nobody uses in practice. Your observation about tweeters is equally valid: most domestic speakers are effective low-pass filters well before 20 kHz at any realistic listening distance.

This is precisely why the tool does not attempt to judge whether the content above 22 kHz is musically meaningful. A vinyl rip at 192 kHz will show genuine content up to the Nyquist limit - but that content is analogue surface noise, cartridge resonance and phono preamp artefacts, not harmonics from the original performance. The tool classifies it as genuine because nothing was upsampled or fabricated - and that verdict is correct within the tool's scope.

Where the tool is genuinely useful is exactly what you described: catching labels and distributors who take a standard 44.1 kHz or lossy master, run it through FFmpeg, and sell it as 24-bit/96 kHz hi-res at a premium price. That is fraud, and the spectral fingerprint of an upsampled lossy source is unmistakable.

The broader question of whether hi-res audio is audibly meaningful at all - given microphone rolloff, tweeter limitations and the boundary of human hearing - is a separate debate. But exposing commercial deception is useful regardless of where one stands on that debate.

 

[Alessandro Comito]

Updated 2026-06-18 Night

• Fixed an issue where dragging and dropping folders with square brackets [] in their names caused the paths to be truncated, preventing the script from processing them.

Under the Hood

• Improved the path resolution logic. The script now correctly passes the full, exact folder names to the analysis engine, bypassing issues with special characters.

 

[Alessandro Comito]

The analysis takes roughly the same time on a 1 MB file as on a 100 MB (or even larger) file because the program does not analyze the entire file.

Instead of processing the whole track second by second, the tool only takes 4-5 short "snapshots" (called slots) at specific points in the song.

You can see it clearly in this example: slot@98s → slot@176s → slot@294s → slot@372s → end@442s

Only these short segments are analyzed with the Hi-Res spectrogram (even though the track is 7 minutes and 22 seconds long).

This applies both to the length of the track (2 minutes or 2 hours makes very little difference) and to the sample rate in kHz (44.1 kHz, 96 kHz, 192 kHz).

A 192 kHz file is much larger because it contains about 4× more samples per second than a 48 kHz file.

However, since the tool only analyzes a few brief segments instead of the entire data stream, the processing time remains almost identical.

In short:
- It is not decoding and analyzing hundreds of megabytes of audio.
- It is only looking at a few scattered seconds of the track, regardless of resolution (kHz) or total duration.
- So it's not thanks to a super-fast CPU, but to the smart, efficient method the tool uses (slot-based sampling).

Result: nearly constant analysis time, whether the file is small or a huge high-resolution one.

P.S. Version 7.7 was released on 2026-06-22.

 

[Alessandro Comito]

Updated 2026-06-23

 

[Alessandro Comito]

Updated 2026-06-24

 

[Alessandro Comito]

Updated 2026-06-25.

 

[Alessandro Comito]

Known limitation
FLAC/WAV files converted from DSD64 to PCM at 176.4 kHz are classified as FAKE by the spectrogram engine.
This is technically correct - the conversion filter cuts at ~40-42 kHz, leaving no content above that frequency - but the signature is identical to an upsample from a 96 kHz source and cannot be distinguished automatically.
If you have DSD-originated files in your library, keep them in a separate folder and exclude it from analysis, or move them back manually after the scan.

 

[Alessandro Comito]

AudioFakeDetector_v7.7_Portable_Offline.7z (2026-06-25) available

 

[Alessandro Comito]

Updated 2026-06-26

 

[Alessandro Comito]

Updated 2026-06-27

 

[ngs428]

Updated 2026-06-27

I have a couple thoughts after testing:

1. The program automatically moves files to a "~Fake" folder. Since I am running this on an existing music library, that will have a negative impact on my music library. Can there be an option to not move ~Fake files?
2. Provide a spreadsheet type report that can be opened in EXCEL, etc., maybe a CSV file that can be opened and analyzed for the results? You can then quickly sort and filter to see the problem tracks without them being automatically moved. I know there is the file generated in the ~Report folder, but I am looking for a more searchable file.
3. If you'd like a wider audience, you can post the GIT link to https://www.reddit.com/r/audiophile/

Thanks!

Edit: When I try to process files in this path: C:\Users\XXXXX\Downloads\8stops7 - Birth of a Cynic [16B-44.1kHz] [FLAC] I get the attached error. If I change the path to C:\Users\XXXXX\Downloads\8stops7 - Birth of a Cynic it works fine. After some more testing, it does not like the dash "-" in the path.

 

[Alessandro Comito]

I have a couple thoughts after testing:

1. The program automatically moves files to a "~Fake" folder. Since I am running this on an existing music library, that will have a negative impact on my music library. Can there be an option to not move ~Fake files?
2. Provide a spreadsheet type report that can be opened in EXCEL, etc., maybe a CSV file that can be opened and analyzed for the results? You can then quickly sort and filter to see the problem tracks without them being automatically moved. I know there is the file generated in the ~Report folder, but I am looking for a more searchable file.
3. If you'd like a wider audience, you can post the GIT link to https://www.reddit.com/r/audiophile/

Thanks!

Edit: When I try to process files in this path: C:\Users\XXXXX\Downloads\8stops7 - Birth of a Cynic [16B-44.1kHz] [FLAC] I get the attached error. If I change the path to C:\Users\XXXXX\Downloads\8stops7 - Birth of a Cynic it works fine. After some more testing, it does not like the dash "-" in the path.

1. Run Start_script_no_move.cmd;
2. absolutely useless for a personal tool, and I have thousands of audio files in as many folders;
3. reddit has banned my account and with new account new post is removed;
4. fixed

Edit: I've decided to keep the core script streamlined and won't be adding native CSV export at this stage to avoid feature creep and keep the codebase focused.
The log is structured linearly, making it very easy to search through or inspect with any advanced text editor.

 

[Alessandro Comito]

Updated 2026-06-29

 

[ngs428]

1. Run Start_script_no_move.cmd;
2. absolutely useless for a personal tool, and I have thousands of audio files in as many folders;
3. reddit has banned my account and with new account new post is removed;
4. fixed

Edit: I've decided to keep the core script streamlined and won't be adding native CSV export at this stage to avoid feature creep and keep the codebase focused.
The log is structured linearly, making it very easy to search through or inspect with any advanced text editor.

Thanks for making the changes! I'll test them out.

Personally, I don't think that a CSV file is absolutely useless. It is a much quicker way to identify the results vs CTRL+F your way thought a huge text file. Please consider in the future.

For my understanding of the process, these results in the log state that it ran auCDtect on 3 audio samples, and results were CDDA 100%, so the file was noted as [OK] auCDtect: CDDA 100%.

[09:28:33] Full analysis (>= 170 kbps) │ Engine: auCDtect (lossless)
[09:28:33] No encoder tag │ flac │ 44.1 kHz │ 2ch │ 16 bit │ 924 kbps │ 00:04:09
[09:28:34] seg1 @62s -> CDDA 100%
[09:28:34] seg2 @124s -> CDDA 100%
[09:28:35] seg3 @186s -> CDDA 100%
[09:28:35] [OK] auCDtect: CDDA 100%


But results like this, still run auCDtect, but they aren't conclusive, so it looks at secondary spectrogram check at 5 specific points.

[09:46:42] Full analysis (>= 170 kbps) │ Engine: auCDtect (lossless)
[09:46:42] No encoder tag │ flac │ 44.1 kHz │ 2ch │ 16 bit │ 709 kbps │ 00:02:24
[09:46:43] seg1 @36s -> CDDA 42%
[09:46:44] seg2 @72s -> CDDA 43%
[09:46:44] seg3 @108s -> MPEG 80%
[09:46:44] auCDtect mixed result: MPEG score=80 | CDDA score=85
[09:46:44] CDDA wins by score weight (scaled confidence: 22%)
[09:46:44] SUSPECT from auCDtect -> running secondary spectrogram check...
[09:46:46] slot@19s(rms=0.127) -> cutoff=21468 Hz | wall=False | ratio=0.417 | peak=79.8
[09:46:47] slot@58s(rms=0.126) -> cutoff=21468 Hz | wall=False | ratio=0.421 | peak=80.1
[09:46:47] slot@92s(rms=0.12) -> cutoff=21446 Hz | wall=False | ratio=0.428 | peak=80.8
[09:46:48] slot@115s(rms=0.12) -> cutoff=21425 Hz | wall=False | ratio=0.44 | peak=83.2
[09:46:49] end@122s -> cutoff=21382 Hz | wall=False | ratio=0.442 | peak=79.6
[09:46:49] Spectrogram secondary: cutoff=21468 Hz | ratio=0.417
[09:46:49] [SUSPECT] auCDtect SUSPECT + spectrogram wall at ~21468 Hz (verify manually)

I ask because this program takes 2x as long to process as auCDtectTaskManager, which uses the same auCDtect engine. While it does not do the spec analysis, but it does produce spec graphs for you and save to the individual album folders.

 

[Alessandro Comito]

Thanks for making the changes! I'll test them out.

Personally, I don't think that a CSV file is absolutely useless. It is a much quicker way to identify the results vs CTRL+F your way thought a huge text file. Please consider in the future.

For my understanding of the process, these results in the log state that it ran auCDtect on 3 audio samples, and results were CDDA 100%, so the file was noted as [OK] auCDtect: CDDA 100%.

[09:28:33] Full analysis (>= 170 kbps) │ Engine: auCDtect (lossless)
[09:28:33] No encoder tag │ flac │ 44.1 kHz │ 2ch │ 16 bit │ 924 kbps │ 00:04:09
[09:28:34] seg1 @62s -> CDDA 100%
[09:28:34] seg2 @124s -> CDDA 100%
[09:28:35] seg3 @186s -> CDDA 100%
[09:28:35] [OK] auCDtect: CDDA 100%


But results like this, still run auCDtect, but they aren't conclusive, so it looks at secondary spectrogram check at 5 specific points.

[09:46:42] Full analysis (>= 170 kbps) │ Engine: auCDtect (lossless)
[09:46:42] No encoder tag │ flac │ 44.1 kHz │ 2ch │ 16 bit │ 709 kbps │ 00:02:24
[09:46:43] seg1 @36s -> CDDA 42%
[09:46:44] seg2 @72s -> CDDA 43%
[09:46:44] seg3 @108s -> MPEG 80%
[09:46:44] auCDtect mixed result: MPEG score=80 | CDDA score=85
[09:46:44] CDDA wins by score weight (scaled confidence: 22%)
[09:46:44] SUSPECT from auCDtect -> running secondary spectrogram check...
[09:46:46] slot@19s(rms=0.127) -> cutoff=21468 Hz | wall=False | ratio=0.417 | peak=79.8
[09:46:47] slot@58s(rms=0.126) -> cutoff=21468 Hz | wall=False | ratio=0.421 | peak=80.1
[09:46:47] slot@92s(rms=0.12) -> cutoff=21446 Hz | wall=False | ratio=0.428 | peak=80.8
[09:46:48] slot@115s(rms=0.12) -> cutoff=21425 Hz | wall=False | ratio=0.44 | peak=83.2
[09:46:49] end@122s -> cutoff=21382 Hz | wall=False | ratio=0.442 | peak=79.6
[09:46:49] Spectrogram secondary: cutoff=21468 Hz | ratio=0.417
[09:46:49] [SUSPECT] auCDtect SUSPECT + spectrogram wall at ~21468 Hz (verify manually)

I ask because this program takes 2x as long to process as auCDtectTaskManager, which uses the same auCDtect engine. While it does not do the spec analysis, but it does produce spec graphs for you and save to the individual album folders.

About the CSV, I completely see your point now, when dealing with huge log files, a structured CSV is lightyears ahead of CTRL+F.
I'm working on implementing it.

Regarding your understanding of the process: You nailed it perfectly.
Case 1: It's straightforward. All 3 segments return 100% CDDA, so the file is instantly marked as OK.
Case 2: The auCDtect engine gets a mixed/uncertain result, so my program automatically triggers the secondary spectrogram analysis. It scans those 5 specific timestamps (slot@...) to measure the actual frequency cutoff, helping you determine if it's a true lossless file or a lossy upscale.

Why is it slower than auCDtectTaskManager? You actually answered your own question at the end! auCDtectTaskManager simply calls the engine and generates the visual spectrogram images.My program, however, doesn't just look at the auCDtect score; when a file is "Suspect", it performs a deep mathematical analysis on the audio data at those 5 points to extract the exact cutoff frequency, RMS, and peak ratios. This secondary DSP (Digital Signal Processing) pass is what takes the extra time, but it provides a much more accurate automated verdict without forcing you to visually inspect every single graph.

 

[ngs428]

About the CSV, I completely see your point now, when dealing with huge log files, a structured CSV is lightyears ahead of CTRL+F.
I'm working on implementing it.

Regarding your understanding of the process: You nailed it perfectly.
Case 1: It's straightforward. All 3 segments return 100% CDDA, so the file is instantly marked as OK.
Case 2: The auCDtect engine gets a mixed/uncertain result, so my program automatically triggers the secondary spectrogram analysis. It scans those 5 specific timestamps (slot@...) to measure the actual frequency cutoff, helping you determine if it's a true lossless file or a lossy upscale.

Why is it slower than auCDtectTaskManager? You actually answered your own question at the end! auCDtectTaskManager simply calls the engine and generates the visual spectrogram images.My program, however, doesn't just look at the auCDtect score; when a file is "Suspect", it performs a deep mathematical analysis on the audio data at those 5 points to extract the exact cutoff frequency, RMS, and peak ratios. This secondary DSP (Digital Signal Processing) pass is what takes the extra time, but it provides a much more accurate automated verdict without forcing you to visually inspect every single graph.

We'll see if my post stays up.. https://www.reddit.com/r/audiophile/s/TGY82QdfuR

 

[Alessandro Comito]

We'll see if my post stays up.. https://www.reddit.com/r/audiophile/s/TGY82QdfuR

I've seen that there are already critics; indeed, with iZotope Ozone 12, if you knew how to use it, you could fool my tool, and more.
Returning to the anonymous track you showed me earlier, it has a cutoff of ~21,468 Hz, so it falls in this range 20,300-22,000 Hz → SUSPECT.
The fix I intend to make is to change this range: cutoff ≤ 22,000 Hz with secondary spectrogram → FAKE, not SUSPECT.
I will proceed with the necessary changes, including implementing CSV file generation.

 

[ngs428]

I've seen that there are already critics; indeed, with iZotope Ozone 12, if you knew how to use it, you could fool my tool, and more.
Returning to the anonymous track you showed me earlier, it has a cutoff of ~21,468 Hz, so it falls in this range 20,300-22,000 Hz → SUSPECT.
The fix I intend to make is to change this range: cutoff ≤ 22,000 Hz with secondary spectrogram → FAKE, not SUSPECT.
I will proceed with the necessary changes, including implementing CSV file generation.

I assume the statement "The only true way to know a source is correct is to have additional evidence material" must refer to log, cue, source images, etc. I have those too, but they are not foolproof. Each is a datapoint to prove or disprove.

Thanks for making the change, it will be a much more useful tool!

 

[ngs428]

About the CSV, I completely see your point now, when dealing with huge log files, a structured CSV is lightyears ahead of CTRL+F.
I'm working on implementing it.

Regarding your understanding of the process: You nailed it perfectly.
Case 1: It's straightforward. All 3 segments return 100% CDDA, so the file is instantly marked as OK.
Case 2: The auCDtect engine gets a mixed/uncertain result, so my program automatically triggers the secondary spectrogram analysis. It scans those 5 specific timestamps (slot@...) to measure the actual frequency cutoff, helping you determine if it's a true lossless file or a lossy upscale.

Why is it slower than auCDtectTaskManager? You actually answered your own question at the end! auCDtectTaskManager simply calls the engine and generates the visual spectrogram images.My program, however, doesn't just look at the auCDtect score; when a file is "Suspect", it performs a deep mathematical analysis on the audio data at those 5 points to extract the exact cutoff frequency, RMS, and peak ratios. This secondary DSP (Digital Signal Processing) pass is what takes the extra time, but it provides a much more accurate automated verdict without forcing you to visually inspect every single graph.

I also posted it to:

https://www.reddit.com/r/Soulseek/s/yAGPRfzlBu