How to Tell If a 320kbps MP3 Was Upscaled From a Lower Quality File

A 320 kbps MP3 that sounds like a 128 kbps file is a common problem, and it is also one of the easiest audio misrepresentations to encounter online. The claim “320 kbps” is often used as shorthand for “best quality”, and sellers, archivists, and casual uploaders will tag a file, rename it, or re-encode it to hit that number without actually delivering the source fidelity that number implies. What you are really trying to check is not whether the file is legally authentic, but whether the technical container matches the advertised encoding, and whether the audio data inside has been upscaled from a lower-bitrate source. Upscaling means a lower-quality file was decoded to raw PCM and then re-encoded at 320 kbps CBR, which inflates the file size and the reported bitrate while preserving the artifacts of the original transcode. That process leaves detectable fingerprints in encoder settings, frame headers, duration vs size math, and in the frequency spectrum. It does not prove who made the file or who owns the recording, it only documents what the file actually contains, which is the kind of technical evidence that matters for verification, archiving, and dispute documentation.

The number 320 kbps is not a quality guarantee. It is the maximum average bitrate for an MP3 frame at the highest quality setting in the MPEG-1 Layer III standard. A true 320 kbps CBR file should be roughly 40 kilobytes per second, so a three-minute track sits around 7.2 MB. If the file is much smaller than that math suggests, the bitrate tag is lying.

A first practical sanity check is size versus duration. Multiply duration in seconds by 40 and compare to file size in kilobytes. A 4:00 track at 320 kbps should be about 9.6 MB. If you see 4.5 MB, the file is not 320 kbps CBR, regardless of what a player displays. Players often read the Xing or VBRI header and report the nominal bitrate, and that header can be rewritten during a re-encode. Next, check whether the file is truly constant bitrate or variable bitrate masquerading as 320. Many “320 kbps” files are actually VBR with an average bitrate around 220-260 kbps, and the max bitrate field is set to 320. That is not necessarily fake, but it is a mismatch with the claim. Sample rate matters too. A genuine high-quality source will be 44.1 kHz. A file that is 32 kHz or 22.05 kHz upsampled to 44.1 kHz will still report 320 kbps but will carry the frequency ceiling of the lower sample rate.

Encoder signatures are the most reliable technical clue. A file encoded with LAME, Fraunhofer, or Apple’s encoder leaves identifiable metadata in the Xing/Info header and in the private bits of the frames. LAME versions are often written into the encoder tag, for example LAME3.100 or LAME3.99.5. When a file has been upscaled, you will frequently see a mismatch: the encoder tag says LAME3.100, but the internal frame data shows joint stereo and bandwidth limitations typical of an older Fraunhofer encode, or the encoder delay/padding values are inconsistent with a single-pass encode. Another tell is the presence of an ID3v2 tag that predates the audio frames, or multiple ID3 tags stacked from successive re-encodes. A clean rip from a CD will typically have one encoder signature and one set of tags. A file that has been transcoded multiple times will show layers of metadata, different timestamps, and sometimes an encoder string that does not match the frame characteristics. This is where systematic metadata extraction helps. Pulling the full MP3 header, Xing header, encoder settings, sample rate, mode, and ID3 tags gives you an objective snapshot you can compare against the claim. A dedicated metadata guide for MP3 files walks through exactly which fields are relevant for this kind of check.

Short practical example helps. Take two files both named “track_320.mp3”. File A is 7.8 MB for 3:15, reports 320 kbps CBR, 44.1 kHz, encoder LAME3.100, and has a single ID3v2.3 tag. File B is 7.9 MB for 3:15, reports 320 kbps VBR, 44.1 kHz, encoder LAME3.99, but the bit reservoir usage is unusually low and the spectral plot shows a hard cutoff at 16 kHz. File A is consistent with a single high-bitrate encode. File B is consistent with a file that was originally encoded at ~192 kbps and then re-encoded at 320 kbps, which preserves the 16 kHz ceiling from the first encode. Neither observation proves malicious intent, but it does prove the technical reality of the file.

The most definitive test for upscaling is spectral analysis. Open the file in a spectrum analyzer such as Spek, Adobe Audition, or Audacity’s Plot Spectrum. A genuine 320 kbps encode from a lossless source will show frequency content extending smoothly up to 20-21 kHz, with natural roll-off and a bit of noise above 18 kHz. An upscaled file will show a sharp vertical line or brick wall cutoff, often at 16 kHz for a 192 kbps source, 16-18 kHz for a 256 kbps source, or 15 kHz for a 128 kbps source. You will also see tell-tale MP3 artifacts: pre-echo, ringing, and a lack of high-frequency detail above the cutoff that does not recover with louder passages. In prose terms, the difference is between a photo with gradual grain and one that has been cropped and then enlarged: the enlarged photo looks bigger but the detail does not return. If you need to document this for a report, screenshots of the spectrogram with time and frequency axes, plus the metadata export, create a reproducible record.

Hashes and file identity are separate from quality but essential for verification workflows. Two files that have different hashes are different files, even if they sound identical. If you are comparing a claimed master against a distributed copy, computing SHA-256, MD5, and CRC32 gives you cryptographic fingerprints that can be stored and later checked for any modification. FilesAudit can extract metadata, compute hashes, and produce a timestamped PDF report for this purpose. That report does not determine legal ownership or authenticity on its own; it documents the technical state of the file at the time of analysis, which is exactly what is needed for auditing, journalism, and compliance.

For a repeatable workflow, start with a metadata extraction to capture encoder, bitrate mode, sample rate, channel mode, and ID3 history. Then verify size versus duration math. Then run a spectral analysis and look for a natural high-frequency tail versus a hard cutoff. Finally, if you need provenance documentation, generate a forensic report with hashes and timestamps. Services like FilesAudit are built for this kind of technical documentation. You can upload a file to extract its metadata, hashes, and AI-provenance evidence and receive a professional PDF that records the findings without making legal conclusions. If you work with many formats beyond MP3, the platform supports 200+ file types across audio, video, images, documents, and CAD, and a desktop option exists for unlimited local bulk analysis when privacy or volume requires it. The goal is not to accuse anyone of deception, it is to have clear, verifiable technical facts about what the file actually is, so you can decide whether the 320 kbps label matches the data inside.