Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: MP3Utility 1.80 Released (Read 13491 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MP3Utility 1.80 Released

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.

MP3Utility 1.80 Released

Reply #1 –
Quote from: mp3utility on
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?
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:
Code: [Select]
Warning: Sync error reading frame header 8,549 expected at byte 5,466,328.  Approx. time: 3:43 (100.0% through audio).
Previous valid frame header located at byte 5,466,224.
Resync failed (reached end of file).

Summary: 8,548 total frames processed (0 padded, 8,548 unpadded).  Bitrate is VARIABLE.

Bitrate summary (excludes VBR header frame, if found):
  32  kbps:     116 frames,     1.4% of total
128  kbps:       22 frames,     0.3% of total
160  kbps:  1,926 frames,   22.5% of total
192  kbps:  4,599 frames,   53.8% of total
224  kbps:  1,124 frames,   13.2% of total
256  kbps:     262 frames,     3.1% of total
320  kbps:     498 frames,     5.8% of total
Average bitrate (actual): 196.1 kbps over 8,547 audio frames.
HTH.

Alessandro

MP3Utility 1.80 Released

Reply #2 –
Quote from: mobyduck on
Quote from: mp3utility on
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?
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:[code]Warning: Sync error reading frame header 8,549 expected at byte 5,466,328.  Approx. time: 3:43 (100.0% through audio).
Previous valid frame header located at byte 5,466,224.
Resync failed (reached end of file).


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

MP3Utility 1.80 Released

Reply #3 –
Sent download link via PM.

Alessandro

MP3Utility 1.80 Released

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

MP3Utility 1.80 Released

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

MP3Utility 1.80 Released

Reply #6 –
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

MP3Utility 1.80 Released

Reply #7 –
so what is this supposed to mean:

Quote
Error: Sync error reading frame header 3 expected at byte 783.  Approx. time: 0:00 (0.0% through audio).
Previous valid frame header located at byte 627.
Resync failed (no matching frame header found within 2,000 bytes).

Summary: 2 total frames processed (0 padded, 2 unpadded).  Bitrate is VARIABLE.

Bitrate summary (excludes VBR header frame, if found):
  48  kbps:  1 frames, 100.0% of total
Average bitrate (actual): 48.0 kbps over 1 audio frames.


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?
--alt-presets are there for a reason! These other switches DO NOT work better than it, trust me on this.
LAME + Joint Stereo doesn't destroy 'Stereo'

MP3Utility 1.80 Released

Reply #8 –
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

MP3Utility 1.80 Released

Reply #9 –
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

MP3Utility 1.80 Released

Reply #10 –
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

MP3Utility 1.80 Released

Reply #11 –
Quote from: mp3utility on
All that said, can anyone comment on the popularity of using the APE tag format for mp3 files?

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.
Can't wait for a HD-AAC encoder :P

MP3Utility 1.80 Released

Reply #12 –
Quote from: mp3utility on
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 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.

MP3Utility 1.80 Released

Reply #13 –
Quote from: mp3utility on
I believe unicode support for file names would be handled by the operating system, not individual applications.  Someone correct me if I'm wrong.

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

MP3Utility 1.80 Released

Reply #14 –
Quote from: robert on
Quote from: mp3utility on

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

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.

MP3Utility 1.80 Released

Reply #15 –
Quote from: odyssey on
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.


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?

MP3Utility 1.80 Released

Reply #16 –
Quote from: mp3utility on
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
FLAC.

MP3Utility 1.80 Released

Reply #17 –
Quote from: mp3utility on
I guess this was the best (and maybe only) way to store this data?

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.
In theory, there is no difference between theory and practice. In practice there is.

MP3Utility 1.80 Released

Reply #18 –
You can store any text in an id3v2.3 tag.

MP3Utility 1.80 Released

Reply #19 –
Quote from: mp3utility on
Any chance either of you can email me a sample file so I can review it?
Sent download link via PM.

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

Alessandro

MP3Utility 1.80 Released

Reply #20 –
Drats, GeoCities has gone the way of the dodo

Are there newer alternatives to this program?

Kind regards.

MP3Utility 1.80 Released

Reply #22 –
On the Mac I use MP3 Scan+Repair. Up until about 2002 a lot of the Mp3s circulating used bad encoders and had sync errors which would manifest as pops and clicks, so it was handy to be able to spot those, but most of the errors I've found since then have been in the header, corrupted seek tables and so forth, with the audio stream still in decent shape. In those cases I use VBRFix or the "fix header" function in Foobar. Only tangentially related, but I'm also still a fan of blasting my MP3 directories with ID3Kill to strip v1 and simplify management.

You're right, though, MP3Utility is pretty fantastic. I can send you a copy of the 1.72/1.80 installer if none of the above work for you.

MP3Utility 1.80 Released

Reply #23 –
the softpedia link worked, but only the RO mirrors (not the US mirrors)
God kills a kitten every time you encode with CBR 320