MP3val 0.1.2 released, A tool to verify MP3 files integrity Options

[Rasqual]

However, it does not support filenames with non-ACP characters.(...)

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

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.

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 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.

[bluewer than blu...]

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.

[ring0]

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)?

[dborn]

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

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.

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

[ring0]

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:

//    ZONE A - Traditional Xing VBR Tag data
//    4 bytes for Header Tag
//    4 bytes for Header Flags
//  100 bytes for entry (NUMTOCENTRIES)
//    4 bytes for FRAME SIZE
//    4 bytes for STREAM_SIZE
//    4 bytes for VBR SCALE. a VBR quality indicator: 0=best 100=worst

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.

[dborn]

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

[ring0]

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.

I meant quite the same

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?

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.

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...(?)

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.

[bluewer than blu...]

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

[jang0]

dito.
Do you still develop mp3val?

[ring0]

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.

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

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).

[sderenzi]

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?

[euphonic]

Sorry to bump an old thread, but I've just run into a minor disaster with my entire 45GB collection of MP3s of all my CDs. I ran "mp3val -f" on all the files before backing them up, and now it turns out the 40GB that were encoded by Lame 3.97 and earlier ran into the inaccurate VBR header length issue and were rewritten. Now the gapless info in the headers isn't correct anymore, and Foobar2k basically plays all tracks with little gaps between them. The enc_padding values are all still in the headers, just wrong; is there an automated way to amend the gapless info for all such files by the necessary number of samples?

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.

Anyone who can help fix this is a hero in my book. Help!!

This post has been edited by euphonic: Oct 21 2008, 09:02

[jaybeee]

Try running a file or two through MP3Packer (try the gui version for ease if on Windows) to see if it helps resolve the problem.

This post has been edited by jaybeee: Oct 21 2008, 20:50