#17 Improvement for the software

[Thiagao]

Hello...
Well I experienced a problem last days when I figured out that an album in my computer was loading the CPU (because windows explorer reads mp3 information in background).
To explain the weird thing I will describe first my enviroment:

Computer: Semprom 2800+ with 2GB RAM,
OS: Windows 7 x64 RC 7100
Player: Winamp 5.56
A folder with 18 mp3 files like the ones hosted on http://www.box.net/shared/dd44ktpan4 (this link contains 4 files: a mp3 file tagged with a bmp picture, the same mp3 tagged with a jpg picture, a bmp picture, a jpg picture)

The problem:
The original mp3 file is tagged with the CD cover which is using the huge/uncompressed bmp format. So, I wanted to replace the bmp picture with another one smaller using the jpg format. For doing this I used the winamp. The weird thing is after I replaced the picture, the mp3 file size didn't decrease so much (it's an absurd that a file with 192Kbps and 4:18 minutes have 11,7MB) and it continued to load my CPU. I tried to edit the tags using another software (Tag & Rename) and it happened the same thing. No software of the same purpose of mp3val I installed detected any problem with the files. I resolved the problem when I used Tag & Rename to remove all tags of the file (that was when the file size descreased a lot). After doing this I recreated the tags, so the problem was resolved. Also, when the files were huge my portable mp3 player didn't load the CD cover, it played the files normally, but it didn't display the CD cover.

So, that was what I have to say.
If you are interesting to add into the software any kind of verification regarding this problem and you need any further information, please contact me.

Thiago

[Nobody/Anonymous]

the id3v2 tag goes at the beginning of the file, and padding is allowed and desired. If an id3v2 tag doesn't exist, or the size of the id3v2 tag needs to grow (maybe by simply adding a comment), then the entire file needs to be rewritten.
It sounds like the program you are using to remove the ID3V2 art is doing the correct thing - it is removing the id3v2 frame that has the art, but just by wiping the data with blank padding. This is the desired behaviour, only a few bytes need to be rewritten instead of re-copying the entire file. If you want the entire mp3 'recompacted' when removing big frames, perhaps the author of the tool used for deleting the art could detect if this now leaves the id3v2 tag at the beginning of the file with more than reasonable padding at the beginning and do the rewrite at a certain threshold.

It is certainly something this tool could do also, but having a large padding is not an error. Something like 'mp3packer' would be an existing tool that optimizes mp3 size, by design rewriting the file, and perhaps could remove excessive padding at the same time if the feature was added to the software:

MP3 Packer version 1.20-195
Copyright 2006-2008 Reed "Omion" Wilson
This program is covered under the GNU GPL.
See gpl.txt or mp3packer.html for more information
Number of processors detected: 2

-b # Minimum bitrate allowed for output. Defaults to 0
-t Strip non-mp3 data at the beginning (mainly ID3v2 tags)
-s Strip non-mp3 data at the end (mainly tags)
-z Recompress frames to find optimal settings (takes time)
-a "-vbr" Changes the string to append to the filename in certain cases
-A Don't skip files in directory which already have the -a string
-u Updates the input file and renames the orig to the output name
-w Silences a whole frame on buffer error. Otherwise skips granule......
.... and so on

[Thiagao]

So the "problem" was the excessive padding... I thought that was any kind of parse error inside the file (because the CD cover was not displayed on my mp3 player screen even when I resized it and because that was loading my CPU)...
I'm a layman when the subject is the mp3 file format heheheeh
The tool you mentioned seems interesting... I didn't know it...

Thank you for the explanations...
Thiago