Hey all,
Just a quick introduction - I am the author of MP3Utility, a program that scans mp3 files for corruption. It's been a while since I updated the program (does 4.5 years count as "a while"?) but I've made some updates and wanted to let people know a new release is available. Please see the link below for additional detail.

Regards,

Peter

http://www.geocities.com/mp3utility/

New features:
1) Fixed the "Sync error reading frame header 2 expected at byte xxx" error. This problem was due to some tagging program or encoder (not sure which) adding non-standard frames between the ID3v2 tag and the start of the audio data. Does anyone know what program is doing this?
2) Double-clicking in the Output Log will now launch the selected file in your default external player. You can click on any line in the Output Log associated with the file you want to play.
3) Right-clicking in the Output Log will copy the full pathname of the associated mp3 file to the clipboard.
4) VBR files will display a bitrate summary (subtotals for each bitrate). This can be disabled in the Options dialog.
5) MP3Utility will now allow multiple instances. If you start the program without specifying a file to test, a new instance will be launched.
6) The location of the last valid header will be displayed when a sync error is encountered.
7) The program will display more than 30 characters of an ID3v2 tag. Selecting data in the tag beyond the right margin will cause the text to scroll right.
8) MP3Utility will now properly display Unicode tags (I think).
9) I have made a few other minor enhancements/bug fixes.

IIRC, I had a similar problem with some files tagged with foobar2000 (v0.8.3, I believe)

I'm sorry to say the issue doesn't seem to be fixed in latest version; just tried a VBR MP3 tagged with foobar v0.9.4.3:HTH.

Alessandro

Alessandro,
The error that was fixed had to do with MP3Utility not being able to find the second frame due to "junk" inserted between the leading ID3v2 tag and the start of the audio data. This is different than the error you posted above - the error above indicates there is some "junk" at the end of the file that doesn't conform to the mp3 standard. I can take a quick look if you want to email me the file.

Regards,

Peter
mp3utility@hotmail.com

Sent download link via PM.

Alessandro

Can you support Unicode file names (names containing accented characters like á or é) as well?

I believe unicode support for file names would be handled by the operating system, not individual applications. Someone correct me if I'm wrong.

To respond to Alessandro's problem with the sync error in the mp3 file:

It turns out the mp3 contains a trailing APEv2 tag followed by an ID3v1 tag. The problem is that MP3Utility has not been coded to recognize APE tags and thus it considers the APE tag to be corrupt audio data. It seems odd that the file contains both an APE tag and an ID3v1 tag. From what I can find, it appears people do this because the APE tag includes the marker "TAG" in its header/footer, which could potentially confuse ID3v1 tagging programs. Finally, it seems that APE tags were originally designed for the Monkey and Musepack audio formats (not mp3), and the use of APE tags for mp3 files introduces various problems (the ID3v1 problem already mentioned plus potential false synchronization problems).

From a developer's standpoint, the use of yet another tagging format is unfortunate as it further complicates the parsing of mp3 files.

All that said, can anyone comment on the popularity of using the APE tag format for mp3 files?

Thanks,

Peter

so what is this supposed to mean:



I've a bunch of those and I'm not sure what makes them different. I tag all my files using mp3Tag (ID3v2 + APEv2). For the ones I got an error, I've removed all tags and re-run it. The error is still there. The log I've posted here is for tagless version of the file.

Any idea?

If you send me a copy of the file (or let me know where I can download it) I can take a look.

Peter
mp3utility@hotmail.com

Peter,

thanks for your efforts.

As Jojo suggested, I tried removing (with foobar) all tags from the sample file I sent you and I get the exact same error.

Alessandro

Foobar must be doing something strange, since the original file processed all the way to the end (up to the APE tag), but after removing all the tags it now fails on the third audio frame. I'll need to take a look and see what's going on.

Any chance either of you can email me a sample file so I can review it?

Thanks,

Peter
mp3utility@hotmail.com

Sure. People use MP3Gain to adjust the volume of their files equally. The APE tags is used to store undo information, so people can revert their files anytime.

To understand what I’m talking about do this:

1) Take any 4 mp3s of your choice put them in a folder and name them as follows:

αβγδεζηθ.mp3
АБВГДЕЖЗ.mp3
אבגדהוזח.mp3
กขฃคฅฆจ.mp3

2) Run MP3Utility on your folder and tell us what you see.

Applications talk to the Operating System via the Programming Interface (API).
Many functions on Windows are there in two variants:
1 functions taking single character strings ending in *A, the ASCII variants take strings in local character encoding
2 functions taking wide character strings ending in *W, the wide characters are unicode strings.
It's up to the application "doing the right thing".

One thing to note is that on NT-based systems such as Windows NT, Windows 2000, and Windows XP, file and folder names are stored as Unicode (a multi-byte character set that includes characters from various ANSI and OEM code pages). Such files and folders can only be processed by Unicode-aware applications. MP3Utility is not a Unicode-aware application at this time. For this reason, MP3Utility can only display and process characters that exist in your current codepage. If your current code page is English 1252, for example, you will not be able to see or process files that have Chinese characters. On the other hand, if your current code page is set to Traditional Chinese - 950, you should see and be able to process files with Chinese characters but you may not be able to see or process files and folders whose names contain Greek characters.

Hmmm. Does it strike anyone else as strange that processing undo information is saved in a metadata format (1) originally meant to store descriptive tags about audio content and (2) designed for a different audio format? Not trying to be obnoxious, but it just seems a bit odd to me...

I guess this was the best (and maybe only) way to store this data?

It should be possible to use ID3v2.4 TXXX tags to store almost any (text) data. I use them to store Replay Gain data, so undo information should fit as well

There's obviously no space in the id3v1 tag. And there used to be a lot anti-id3v2, a tagging format that introduces many problems. So foobar2000 up to versions 0.8.x used always APEv2 tags on mp3 for additional tags, not only replaygain values but also longer fields than id3v1 permits and extra tags.
I don't think the APEv2 tags were designed for specific audio formats and could be adopted by other formats as well. But that makes thus tagged files sometimes "out of spec".
Nowadays the id3v2.4 tagging library (at least the one foobar200 uses) seems to have found a way around the previous problems with id3v2.

You can store any text in an id3v2.3 tag.

Sent download link via PM.

But, I just repeated the test without tags and now no errors are found... apologies.

Alessandro