My collection contains some MP3s which have some glitches like:

  • displaying the wrong duration on loading
  • minor jumps
  • suddenly ending despite the duration claims another minute remaining
  • noise

I'm looking for a tool that can detect as many of these glitches as possible and fix those that can be fixed (obviously e.g. noise can not simply be eliminated in most cases).

  • Those sound like player issues. Are you sure those are caused by your MP3 files?
    – digitxp
    Aug 24 '11 at 14:59
  • @digitxp the sudden ending is probably due to missing parts of the file, but the wrongly displayed time might be caused by VLC. But still that means there is something wrong with the file since other files show the correct time. Noise and jumps might be due to a bad CD read, I digitalized my collection without doing double-checks :-/ Aug 24 '11 at 15:02
  • hm, the wrong duration could stem from VBR vs CBR... so the remaining problems are incompleteness and CD reading errors Aug 24 '11 at 15:17

The command-line tool mp3val makes quick work of scanning for, and optionally repairing, structural defects in mp3 files. I try to run it over pretty much every file in my collection, on the "can't hurt" principle. It identifies amazing numbers of ostensibly-good files with defects ranging from inconsequential to severe.

mp3val is especially good at recognizing and correcting header deficiencies, such as lack of VBR headers in a VBR file (the source of most wrong-duration and seeking issues). But it will also clear out garbage/corrupted audio frame data, unusable cruft that some players may handle less than elegantly if it's left in the file.

It can even be told to run over an entire directory of mp3's, repairing only those files it finds problems with, keeping backups (or optionally not), preserving timestamps (optionally), and logging the session to a text file (optionally).

And it's free and open source! (The link is to its sourceforge project.)

EDIT: One last thing I forgot to mention. "But mp3val hasn't been updated since 2009!!", I hear you cry. That's very true! It's been working just fine since 2009, and hasn't needed an update. (After all, it's not like the MP3 file format has changed any in the past 2 years!)

  • also +1 a second time for you edit :-) though there seem to be some valid bugs still open... Aug 26 '11 at 15:04
  • 1
    Yeah, it seems mp3val has some real problems under Windows 7 with some esoteric filenames. That's unfortunate. (First rule of modern computing: any sufficiently large MP3 collection will contain a file with any given form of esoteric filename.) It could use some luv from a Windows programmer, if anyone's up to it! [OffTopic: It was surreal looking into the mp3val svn and finding out that the most recent patch had come from ME — especially since I'd totally forgotten about doing it! ;-)]
    – FeRD
    Dec 20 '11 at 20:40
  • 1
    Unfortunately mp3val failed to fix some of my files :(. But MP3Diags was able to fix them (Xing header on VBR files which lead to a wrong duration being displayed).
    – scai
    Oct 29 '13 at 16:50
  • @Marecky That's very strange. I just tried mp3val on Fedora 28, and it's still running fine. The most esoteric library dependency it has is either libm.so.6 or libstdc++.so.6, so it's not like an incompatible ABI breakage is likely. Just to check, though: in its default mode mp3val won't touch any files, it'll only make modifications if it's run with the -f flag — and even then, only files where the scan mode logged a WARNING: or ERROR: would be modified. If it doesn't detect any fixable issues, it'll leave your files untouched.
    – FeRD
    Nov 2 '18 at 23:40
  • 1
    @FeRD - You are right, I don't remember now which program was it (Audacious, Gnome MPV or Rhythmbox Music Player) but after ripping a cd with the last one I put new files into playlist of one of these programs and saw wrong track times - that is why I thought that mp3's have wrong indexes (or whatever that have inside) and run on them mp3val - but the files were correct - that is why mp3val never displayed any warning and didn't correct files. I don't know why player showed wrong track times, I will delete my previous comment.
    – Marecky
    Nov 7 '18 at 12:28

I assumed you already tried the first option on google ...? Also a perl script, mp3checker, that might be useful.


As for repairing your tracks might give MP3 Diags(links to a lifehacker article) a look.

  • thanks, checkmate is a nice tool to identify problem files (that still leaves the task of fixing things if possible though) Aug 24 '11 at 15:14
  • 1
    Thumbs up for MP3 Diags. I had problems with my mp3 player not reporting the duration correctly. MP3 Diags found and fixed the problem.
    – David L
    Jan 23 '13 at 4:54

mpck works on Windows and GNU / Linux.

Home page: http://checkmate.gissen.nl/

It detects bad frames and generates optional reports.
There is a GUI frontend for windows too.

mpck 0.19 - checks a MP3 file for errors

Usage: mpck [OPTION]... [FILE]...

   -v, --verbose        print some extra info
   -q, --quiet          print only Ok or Bad per file
   -B, --badonly        only report bad files
Other options:
   -R, --recursive      check directories recursively
   -e, --extention=EXT  only check files ending on .EXT
   -r                   short for -R -e mp3
   -m, --maxname=NUM    report bad for filenames which exceed NUM characters
   -n, --namecheck      check for strange characters in the filename
   -x, --xmloutput      output results in XML
   -h, --help           print this help, then exit
   -V, --version        print version information


This program seems to be fully capable of handling utf-8 file names, although I haven't tried japanese, chinese or more exotic glyphs.

Gentoo (UTF-8)

$ mpck -r 2000\ -\ Завтрак\ на\ траве\ \(USA\)/  | grep SUM
SUMMARY: 2000 - Завтрак на траве (USA)//04-ja-sbrasyvaju-kozhu.mp3
SUMMARY: 2000 - Завтрак на траве (USA)//07-tak-vot-kakaja-ty-demo.mp3
SUMMARY: 2000 - Завтрак на траве (USA)//09-evrej-i-goj.mp3
SUMMARY: 2000 - Завтрак на траве (USA)//06-teplyj-dozhd'-demo.mp3
SUMMARY: 2000 - Завтрак на траве (USA)//01-vse-napominaet-o-tebe.mp3
SUMMARY: 2000 - Завтрак на траве (USA)//02-marsh-novoselov--sf-unplugged.mp3
SUMMARY: 2000 - Завтрак на траве (USA)//05-rubaha.mp3
SUMMARY: 2000 - Завтрак на траве (USA)//03-kalifornia-love.mp3

Cygwin with UTF-8 locale (japanese locale in windows)
The native windows binary is not aware of cygwin so I had to convert the output.

$ mpck.exe -r "2000 - Завтрак на траве (USA)" | grep 'SUM' | 
       iconv -f CP932 -t UTF-8
SUMMARY: 2000 - Завтрак на траве (USA)\04-ja-sbrasyvaju-kozhu.mp3          
SUMMARY: 2000 - Завтрак на траве (USA)\07-tak-vot-kakaja-ty-demo.mp3       
SUMMARY: 2000 - Завтрак на траве (USA)\09-evrej-i-goj.mp3                  
SUMMARY: 2000 - Завтрак на траве (USA)\06-teplyj-dozhd'-demo.mp3          
SUMMARY: 2000 - Завтрак на траве (USA)\01-vse-napominaet-o-tebe.mp3        
SUMMARY: 2000 - Завтрак на траве (USA)\02-marsh-novoselov--sf-unplugged.mp3
SUMMARY: 2000 - Завтрак на траве (USA)\05-rubaha.mp3                     
SUMMARY: 2000 - Завтрак на траве (USA)\03-kalifornia-love.mp3            
  • Thanks, though that's already been mentioned in this answer Jul 24 '13 at 6:57
  • mpck != mp3check. Am I wrong? Jul 24 '13 at 7:11
  • No, it's the link labelled "the first option on google". But +1 nonetheless since you elaborate a bit on it's functions Jul 24 '13 at 7:12
  • Oh, right. I ignored that. I'll be checking out mp3val, but so far mpck has been able to to all that I need from an mp3-checker. Jul 24 '13 at 7:14
  • 2
    On Linux, it doesn't strike me as necessary to apply any workarounds for mp3val — AFAICT the referenced bug is a Windows-only problem. (Whatever functions it uses for parsing the command line or handling filenames must not be Unicode-safe.) Under Linux, I just hand-damaged (by zeroing out random blocks with ghex) mp3 files renamed as follows: Tësting 1.mp3 Testíng ®eally hµrd.mp3 ☭They don't get much weirder☭.mp3 ...mp3val had no trouble correctly processing all of them.
    – FeRD
    Oct 8 '13 at 9:47

Simpler is to use ffmpeg to copy the file from the one with the faulty duration in its ID3 tag. This causes it to write the correct information.

ffmpeg -i "audio.mp3" -acodec copy "audio_fixed.mp3"

Because it uses copy it takes a fraction of the time the original encoding takes. This is hardly noticeable with a song, but you really appreciate it with a 7 hour audiobook. After re-encoding, the ID3 tags now have the correct information.

Not the answer you're looking for? Browse other questions tagged or ask your own question.