• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Audio Fake Detector PRO

awesome work!
check this out -
this is a "hi-res" file i downloaded from Tidal

[13:07:28] [1/1] Z:\OrpheusDL\downloads\Sharon Van Etten - Sharon Van Etten & The Attachment Theory\02.
Afterlife.flac
[13:07:36] Full analysis (bitrate >= 170 kbps).
[13:07:36] Engine: spectrogram (Hi-Res 96000 Hz - auCDtect bypassed).
[13:09:50] slot@40s(rms=0.243) -> cutoff=23413 Hz | wall=False | ratio=0.516 | peak=99.2 | NR=False
[13:10:08] slot@109s(rms=0.376) -> cutoff=24352 Hz | wall=False | ratio=0.518 | peak=127.6 | NR=False
[13:10:26] random@159s(rms=0.237) -> cutoff=23554 Hz | wall=False | ratio=0.54 | peak=102.4 | NR=False
[13:10:44] slot@189s(rms=0.468) -> cutoff=24117 Hz | wall=False | ratio=0.532 | peak=144.1 | NR=False
[13:11:02] end@226s -> cutoff=23742 Hz | wall=False | ratio=0.515 | peak=109.8 | NR=False
[13:11:14] [FAKE] Spectrogram Hi-Res: cutoff ~24352 Hz (<= 28 kHz) - upsampled from 48 kHz standard source
[13:11:14] 2681 kbps | 248 s
[13:11:14] MOVED -> ~Fake\02. Afterlife.flac
[13:11:14]
[13:11:14]
[13:11:14] =========================================================================================================
[13:11:14] SUMMARY
[13:11:14] =========================================================================================================
[13:11:14] Files found : 1 (including hidden)
[13:11:14] Analyzed : 1
[13:11:14] Skipped : 0
[13:11:14] OK : 0
[13:11:14] FAKE : 1
[13:11:14] SUSPECT : 0
[13:11:14] UNKNOWN : 0
[13:11:14] Orphan dirs : N/A (file-mode scan)
[13:11:14] =========================================================================================================
[13:11:14] Reports : Z:\OrpheusDL\downloads\Sharon Van Etten - Sharon Van Etten & The Attachment Theory\~Report
[13:11:14] Log : Z:\OrpheusDL\downloads\Sharon Van Etten - Sharon Van Etten & The Attachment
Theory\~Report\AudioFakeDetector_20260531_130728.log
[13:11:14] CSV : Z:\OrpheusDL\downloads\Sharon Van Etten - Sharon Van Etten & The Attachment
Theory\~Report\AudioFakeDetector_20260531_130728.csv
[13:11:14] HTML : Z:\OrpheusDL\downloads\Sharon Van Etten - Sharon Van Etten & The Attachment
Theory\~Report\AudioFakeDetector_20260531_130728.html
[13:11:14] =========================================================================================================

seinfeld-julia-louis-dreyfus.gif

What format was the file specified as (bit depth/sample rate)?

Sort of depends on what Tidal (or anyone else) defines as high res. I can't see from that output if the tool detects bit depth for example. If the file upsampled from were 24/49 - that might legitimately be called high res. Though it would probably be dishonest to upsample that to a higher sample rate.

Having said that - high res (above CD) music files are another example of industry snake oil. If masters are the same then the "high res-ness" is going to be inaudible in real world listening - and in many cases - as has been demonstrated here, much of the higher bandwidth is just filled with ultrasonic noise.
 
What format was the file specified as (bit depth/sample rate)?

Sort of depends on what Tidal (or anyone else) defines as high res. I can't see from that output if the tool detects bit depth for example. If the file upsampled from were 24/49 - that might legitimately be called high res. Though it would probably be dishonest to upsample that to a higher sample rate.

Having said that - high res (above CD) music files are another example of industry snake oil. If masters are the same then the "high res-ness" is going to be inaudible in real world listening - and in many cases - as has been demonstrated here, much of the higher bandwidth is just filled with ultrasonic noise.
In that earlier release, when a file triggered the Hi-Res spectrogram engine (bypassing auCDtect), the log went straight to the slot analysis without printing the initial file properties (like nominal sample rate and bit depth). It only showed the average bitrate (2681 kbps) at the end.

This has been fixed in newer versions: the tool now extracts and displays the full container metadata (e.g., flac | 96 kHz | 2ch | 24 bit) right at the beginning of the analysis, regardless of which engine is running.
 
@Alessandro Comito I thought auCDtect could only process 16 bit 44.1kHz file, I see it shows as the engine used on some of my 24 bit 88.2kHz files. Can you please explain?
 

Attachments

  • Screenshot 2026-07-01 065518.jpg
    Screenshot 2026-07-01 065518.jpg
    23.4 KB · Views: 31
Updated 2026-07-01
  • Added 88.2 KHz support
  • Added CSV support: on selection window, click to cycle: [CSV ( )] → [CSV ( , )] → [CSV ( ; )] → [CSV ( )]
 
Last edited:
Post removed
Saw that... Not much conversation there anyway.

On the latest version, are there any large bugs that would prevent me from scanning several thousand files? 16/44.1, 24/48, 24/96, 24/88.8, 24/192 are examples...
Has there been any tests done queuing 5,000 files and running to completion?
 
Saw that... Not much conversation there anyway.

On the latest version, are there any large bugs that would prevent me from scanning several thousand files? 16/44.1, 24/48, 24/96, 24/88.8, 24/192 are examples...
Has there been any tests done queuing 5,000 files and running to completion?
The latest version processes files sequentially one by one, so there are no memory leaks or crashes related to large queues.
It fully supports mixed formats from standard 16/44.1 up to Hi-Res 24/192, and the processing time per file is nearly identical regardless of the format or resolution. A queue of 5,000 files will run to completion successfully.

Additionally, if the external hard drive disconnects during the analysis or if there is a power outage, you don't have to restart from scratch.
Just restart the tool, select the exact same folder you chose before, and you will be prompted to resume the queue right after pressing Start.
 
The latest version processes files sequentially one by one, so there are no memory leaks or crashes related to large queues.
It fully supports mixed formats from standard 16/44.1 up to Hi-Res 24/192, and the processing time per file is nearly identical regardless of the format or resolution. A queue of 5,000 files will run to completion successfully.

Additionally, if the external hard drive disconnects during the analysis or if there is a power outage, you don't have to restart from scratch.
Just restart the tool, select the exact same folder you chose before, and you will be prompted to resume the queue right after pressing Start.
Awesome. I will give it a larger test over the next few days.

Functionality wise is there any difference between standard and portable. It does not seem like there is. Which makes sense.
 
Awesome. I will give it a larger test over the next few days.

Functionality wise is there any difference between standard and portable. It does not seem like there is. Which makes sense.
The power went out and the analysis resumed from the first track, I need to fix this bug :(
 
The power went out and the analysis resumed from the first track, I need to fix this bug :(
Hopefully this does not happen to me.. 15k out of 54k tracks in. Been going for about 13 hours straight. Haven’t reviewed any results yet though.
 
Hi Alessandro,
great tool, thank you!
As I got my files organised by one album per folder (about 5000), an option to analyse only the first file of a folder would speed up the scan a lot (as until now, when one file of an album was fake, the whole album was).
 
Hi Alessandro,
great tool, thank you!
As I got my files organised by one album per folder (about 5000), an option to analyse only the first file of a folder would speed up the scan a lot (as until now, when one file of an album was fake, the whole album was).
I understand the desire for a 'first-file-only' scanning option to speed up large library audits. However, I have decided against implementing this feature, and here is why:

My primary goal for the tool is maintaining high accuracy and minimizing false positives/negatives. Relying on a single file, specifically the first one, is statistically risky.

In my testing, I've found that genres like Dark Ambient, Drone, or even certain concept albums often feature an 'intro' track that significantly differs from the spectral content of the rest of the album. Basing an entire folder's verdict on a single potentially anomalous track would compromise the integrity of the analysis.

I believe it is better to invest the extra time to ensure the results are reliable, rather than sacrificing precision for speed.

If you have a very large library, my recommendation is to simply let the tool run in the background whenever you have the time.
It is designed for mass processing, so you can set it to work and let it complete at its own pace. The accuracy of the final report is worth the wait.

Bug i have to fix: the power went out and the analysis resumed from the first track.
 
It finished scanning 55k FLAC tracks, took 2 days. I've started to analyze the results. I found it helpful to first determine the percentage FAKE or SUSPECT per album. That allowed me to determine which albums were deemed 100% fake, or 100% suspect and review those first. I did that via some EXCEL formulas (mainly countif) using the CSV output. I did that because those albums likely had issues vs looking at an album that has 40% FAKE, if the other 60% were OK, I suspect the entire album is OK. Most of my albums are CD rips with log files. But some purchased digital files.

The first couple albums on the list I ran through spek and sure enough, they were bad. So, very useful for me once I broke it down into an album analysis.

One thing I noticed is that if flagged 66% of my 88.2/24 FLAC SACD rips as SUSPECT or FAKE. With text such as below, I need to spek those yet. I doubt these are FAKE or SUSPECT.
Spectrogram Hi-Res: cutoff ~28840 Hz at 88.2 kHz - ratio=0.803 (>0.5) and slope=0.532 indicates a steep digital brickwall filter; would normally be FAKE, but the slope threshold is calibrated for 96 kHz files only - capped at SUSPECT for 88.2 kHz until dedicated calibration exists. Manual inspection with a spectrogram tool recommended.
 
It finished scanning 55k FLAC tracks, took 2 days. I've started to analyze the results. I found it helpful to first determine the percentage FAKE or SUSPECT per album. That allowed me to determine which albums were deemed 100% fake, or 100% suspect and review those first. I did that via some EXCEL formulas (mainly countif) using the CSV output. I did that because those albums likely had issues vs looking at an album that has 40% FAKE, if the other 60% were OK, I suspect the entire album is OK. Most of my albums are CD rips with log files. But some purchased digital files.

The first couple albums on the list I ran through spek and sure enough, they were bad. So, very useful for me once I broke it down into an album analysis.

One thing I noticed is that if flagged 66% of my 88.2/24 FLAC SACD rips as SUSPECT or FAKE. With text such as below, I need to spek those yet. I doubt these are FAKE or SUSPECT.
Spectrogram Hi-Res: cutoff ~28840 Hz at 88.2 kHz - ratio=0.803 (>0.5) and slope=0.532 indicates a steep digital brickwall filter; would normally be FAKE, but the slope threshold is calibrated for 96 kHz files only - capped at SUSPECT for 88.2 kHz until dedicated calibration exists. Manual inspection with a spectrogram tool recommended.
Can you attach the log recorded in the ~Report folder?
Actually, since I don't have 88.2 kHz audio files, I couldn't establish completely reliable thresholds.
Generally, an album can have some tracks that are clean and others that are fake if they contain lossy material, even if they come from CDs.
 
Back
Top Bottom