I've written and released a small tool for MPEG audio files validation (supports MPEG-1, 2, 2.5, Layers 1, 2, 3). I think it can be quite handy for finding corrupted MP1/MP2/MP3 files (e.g. containing garbage, MPEG stream errors, truncated etc.). Information in VBR headers (VBRI/Xing) is also checked, however, not all of it yet.

It can also "fix" most of the problems (of course, it is questionable if one should fix MPEG stream errors, for example).

This is a command-line application, it should work both under Windows and Unix.

More information can be found on the Project Homepage

I'm interested in your comments.

very nice, and being open source is really a plus. would check it.

This 20KB (!) program scanned 251 MP3s (1.85 GB) and wrote a log file three times its size in 41 seconds. Pretty goddamn amazing! Open source, wildcard support, blazing speed, and did I mention it is tiny?
Congratulations, ring0 - well done! Hope you will write a GUI for it, too <g>.

i'm going to play with it and package it for Rarewares/Debian if you don't mind


later

I downloaded the Win32 version from one of the mirror sites.

I copied mp3val.exe to the drive/folder where certain mp3 files live.

I selected Run off the Start menu and Browsed to find and select mp3val.exe

The Run command line now says G:\temp\mp3val.exe.lnk
The .lnk is not shown by WindowsExplorer

I add an mp3 file name (file to validate) and the log file parameter, as explained in the program documentation.

I clicked on OK. Something happens because there is the flash of a window opening, but it is gone before more than the outline can be seen. No log file can be found anywhere on the computer.

I selected the MS-DOS Prompt and got the DOS window.

I navigated to the proper folder.

I tried every variation I can think of on mp3val (mp3val, mp3val.exe, mp3val.exe.lnk, and mp3val~1.lnk (which is what the DIR command displays) and a few others). Every one produces the message Bad command or file name

Does the (hidden) .lnk extension indicate I don't have an executable?
If so, is there an executable at some other site?
Is some addition component, DLL, or whatever necessary to run this program?
Have I misunderstood the meaning of MP3val is a console program. Command-line syntax: from the program documentation?

Sounds like you accidentally created a shortcut to the original file rather than copying it. A .lnk file is a shortcut. Then, if you deleted the original, the link would be pointing nowhere so no program would be run.

Nick

Thanks, I obviously didn't look closely enough; perhaps I just wasn't careful with that mouse pointer during the copy. Since the original was still in place, it must be that the Run command doesn't handle the pointer correctly.

How does this program compare to mp3check?: http://jo.ath.cx/soft/mp3check/mp3check.html

I haven't seen this programs before I've written MP3val. If I had, may be I wouldn't write it. However, there are some differences:
- MP3val analyzes VBR headers (Xing, VBRI), mp3check seems not
- MP3val is a "native" Windows program (and was later ported to *nix), mp3check isn't (it needs Cygwin)
- MP3val supports ID3v1, ID3v2, APEv2. mp3check seems to support only ID3v1
- MP3val detects RIFF headers (however, mp3check also deals with them: it claims it is a garbage
- MP3val doesn't support CRC calculation and fixing yet (however, rather small amount of files has CRC)
- mp3check has more parameters (but most of them seems to be not very useful)
- MP3val has significantly smaller size (at least in Win32)

Anyway, it's good that users will have a choice

thanks! it worked perfectly for me, fixed a file that i've had problems with.

Great job ring0...a simple gui would be perfect for those not really into command based stuff. Think about it if you ever find the time...

I've tried a lot of apps to analyze and check my MP3s, but none of them has been as fast and compact as MP3val. Thanks for this useful tool.

Feature request:
A switch to reduce the output to errors and warnings only. That way it'd be much easier to spot problematic files when mp3val is used with wildcards (like *.mp3).

MP3val 0.1.3 released, this feature is implemented in it, as well as a few minor bugfixes and improvements.

http://mp3val.sourceforge.net

What about a frontend, I think I will write it when I have enough time and desire

This is another one. MP3Utility

Nice The only drawback is that it can't fix files.
Strangely enough, MP3utility displays all general errors in "test file" mode, but only few of them in batch mode.

Anyway, having a GUI is a big "+"

Great tool, thanks for your work.

Could it be possible to recurse through directories?

Narag

It is possible (at least, currently) only with the help of FOR command.
You should start CMD.exe, go to your directory and write:

for /r %i in (*.mp3) do mp3val "%i" -llog.txt

Recursive directory analisys will be in the GUI frontend when I (at last) write it

Thanks for the -si option.

There is also a GUI version of mp3check called MP3Test, but I don't think it has been updated to support VBR files like its commandline counterpart. It looks to be shareware, but I don't ever remember having to pay for it. Go here for more info: http://www.shivi.de/MP3Test/

When I run MP3Val on my newly LAME generated mp3 files, I get the same message for each file: "Wrong number of MPEG data bytes specified in Xing header (10047046 instead of 10046717)".

The difference is always 329 bytes. I removed all tags (ID3v1.1, ID3v2.3, APEv2) and I still get this same error message. What's the Xing header anyway?

Thanks,
Daniel

I've been using Checkmate MP3 checker (GNU GPL) and am satisfied about it (unverbose output is appreciated).

However, it does not support filenames with non-ACP characters. Nor does yours, but since yours rooted from Win32, it was easier to adapt to my purposes to recompile a compatible version.

Notes about the code quality: you should avoid unnecessary (C-style or not) type casts when possible. It can hide defects.

Edit: A shell extension version would be appreciated, if you're not afraid of possibly leaking explorer resources (lol)

Put the program executable in your system32 folder.

Xing header is encapsulated in the first MPEG frame, it can be recognized by a "Xing" or "Info" strings.

Btw, what version of LAME do you use and what options? My LAME-generated files doesn't produce such effects.

Do you mean "\\?\..."-like paths?

Very nice tool indeed, thanks!

As far as the GUI goes, I prefer the CLI as it lets you retain full control and enables the prog to be compact, but that's just me it seems.

I mean foreign characters, such as CJK characters on an English system or Czech on a Korean locale.
I switched quite a bunch of char to TCHAR, but I'm afraid it makes it a pain to compile on gcc.


I agree. However, a GUI would save some time when trying to check several specific files at a time and can present results in a more legible way.

I can't find an excuse for not having two different "versions"...one with GUI (when and if implemented) and one without for everyone to be happy.

I'm planning to do so.

Btw, may be I should make two versions for Windows (one with Unicode, and one without - for Win95/98)?

I'm using lame 3.97b2. I've experimented with it alot this morning and I have found some interesting results:

lame.exe -V 2 --noreplaygain test.wav test.mp3
produces no error. No ID3 tags and a Xing header.

lame.exe -V 2 --noreplaygain --ta "test" test.wav test.mp3
produces the error (128 bytes too many in Xing). Only writes an ID3v1 tag and Xing (lame?) tag.

lame.exe -V 2 --noreplaygain --add-id3v2 --ta "test" test.wav test.mp3
produces the error (181 bytes too many in Xing). Writes an ID3v1 & ID3v2 and Xing tags.

lame.exe -V 2 --noreplaygain --add-id3v2 --only-id3v2 --ta "test" test.wav test.mp3
produces the error (181 bytes too many in Xing). Writes an ID3v1(!) & ID3v2 and Xing tags.

lame.exe -V 2 --noreplaygain --add-id3v2 --only-id3v2 --pad-id3v2 --ta "test" test.wav test.mp3
produces the error (309 bytes too many in Xing). Writes an ID3v1(!) & ID3v2 and Xing tags.

lame.exe -V 2 --noreplaygain --add-id3v2 --only-id3v2 --pad-id3v2 -t --ta "test" test.wav test.mp3
produces no error. Writes an ID3v1(!) & ID3v2 and no VBR header.

No matter how much tag manipulation I do using Mp3tag afterwards, it will not change anything with the Xing header size discrepancy.

It certainly looks like lame.exe 3.97b2 has a bug! Should I use mp3val to correct the problem or should I leave it alone? I'm certainly tempted to not let lame add any tags to my mp3 files anymore...

Thanks,
Daniel

I've analyzed the case, it looks like there are different opinions about storing number of bytes in the Xing header:
- LAME stores total number of bytes in file
- foobar2000 (in "fix header" mode) and MP3val store number of MPEG bytes in file, that is, a previous value minus total tags size

If we look into MP3 Info tag specification (Info header is used by LAME and is an extension of Xing header), we shall see:


I think STREAM_SIZE is rather self-explainable and it should mean number of bytes in stream, not file. But other opinions may exist (look http://www.codeproject.com/audio/mpegaudioinfo.asp)

May be it doesn't worth fixing all these files, because this value (number of bytes) has a negligibly small impact on average bitrate calculation.

Anyway, I'll think about taking this behavior into account (not to produce a warning message when number of bytes specified in Xing header equals total number of bytes in file, not in MPEG stream).

Thank you for your useful report.

Maybe you could check if value is equal to stream size OR file size and accept both as "good". As long as this value is not used for any offset calculation, it shouldn't matter too much.

Still, it's funny that when lame doesn't add any tags at all, mp3val doesn't find a problem with the numbers not matching... Surely there must be some non-stream data in the file even when no tags are written?

I guess there might be another problem if additional tags get written later on. This means that the Xing header reported size would again not match the file size...(?)

At first I was thinking that the Xing/Lame header had a discrepancy on purpose so that mp3 files could be played gaplessly (not counting the blank samples at the end) but then the reported size should have been smaller than the actual stream size, not bigger...

I've been looking for a good mp3 file validator (one that's still supported also) so it's my pleasure to help out anyway I can...

Daniel

I meant quite the same


When LAME doesn't add any tags at all, file size equals to stream size, so that "lame" method and "foobar2000/MP3val" method give the same results.



That's why I think that Xing header should better store stream size, not file size. So, a question about what to do if "lame" behavior was detected during validation, is still opened.

Just wondering if there's any progress with the program and especially regarding the gui issue.

dito.
Do you still develop mp3val?

Occasionally, I do. MP3val 0.1.5 is just out (see http://mp3val.sourceforge.net).
There are still some things to be done (e.g.: check CRC in the frames, check VBR header for table of contents validity, insert VBR header if there's a VBR file without it). Unfortunately, mp3val development isn't my primary interest now.



I've started to write a windows GUI but I dropped it when I couldn't think out any easy method of handling listboxes with thousands of elements.

Erich Schubert has written a simple frontend for mp3val (http://blog.drinsama.de/erich/en/2007020401-mp3val-gui.html), but it requires PyGTK and it can be difficult to run under Windows (personally I didn't manage to do it).

Wow is this an old entry, but honestly I think I'm experiencing something similar to this with 0.1.7

Basically when I audit my mp3's with your utility I find they are all accurate, but when I use foobar it tells me "Reported length is inaccurate". Now normally your tool would fix this but what I've found is that it cannot, and infact they seem to conflict with eachother. I think the conversation here has something to do with my issue but am not sure.

The reason foobar claims the file is not right is due to the gapless playback padding, which if I make it lower will stop being an issue, but if I do any editing mp3val claims the Xing header is wrong!

So which one is right? I am assuming that when I alter the gapless playback padding this changes the size of the mpeg stream somehow which throws off the Xing headers stored value, but then why does your utlility fix the files but not put a value that's right (and will verify in foobar)??? It's confusing...

See I fixed a few of my mp3's with mpeg stream errors, used your utility, it was ok. But the gapless playback padding was never corrected to match those samples missing, so in effect foobar is correct when it claims the length is wrong, it's because they were corrupt somewhat. But how can I adjust is without messing up the Xing header?