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: MP3 repacker (Read 587804 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MP3 repacker

Reply #450
Install c++ 2008 redistributable


Thank you.  I'll give that a try.
I guess that rules out getting it to work on my older Win 98se machines, as the previous versions did.  Luckily, my main machines are the XP and the 2000 ones.

What did you compile the older versions with, since they worked well on everything? I may just compile my own, as it is too useful to not have on every system.
--
FoxWolfie

MP3 repacker

Reply #451
I have an enhancement request to what the -s and -t options can already do.  Can we have an extra option to keep ID3v1 and ID3v2 tags, but that strips all other tags and non-mp3 data, such as LYRICS or APETAGs.  I've seen several times where alternative tags were improperly written, and attempts at removing them also killed the ID3 tag.  I end up needing to remove those tags with a hex editor, which works, but is slow and prone to accidents.
--
FoxWolfie

MP3 repacker

Reply #452
Great idea, FoxWolfie!

On a sidenote, although Mp3Packer might be up for the job as well, if implemented, I'm currently trying to find a program that can automatically extract images from the metadata and saves it as Folder.jpg IF there's none already in that folder, and removes them from the audio files afterwards. Does anyone know a program that can do this already?

MP3 repacker

Reply #453
Great idea, FoxWolfie!

On a sidenote, although Mp3Packer might be up for the job as well, if implemented, I'm currently trying to find a program that can automatically extract images from the metadata and saves it as Folder.jpg IF there's none already in that folder, and removes them from the audio files afterwards. Does anyone know a program that can do this already?

Does this help???
http://vcardenasblog.blogspot.com/2008/09/...or-rockbox.html
You can run it on any folder...just sayin'

MP3 repacker

Reply #454
Great idea, FoxWolfie!

On a sidenote, although Mp3Packer might be up for the job as well, if implemented, I'm currently trying to find a program that can automatically extract images from the metadata and saves it as Folder.jpg IF there's none already in that folder, and removes them from the audio files afterwards. Does anyone know a program that can do this already?

Does this help???
http://vcardenasblog.blogspot.com/2008/09/...or-rockbox.html
You can run it on any folder...just sayin'

Not sure if that will delete it afterwards but with Mp3tag you can remove art from MP3's in bulk so maybe between the 2 programs???

MP3 repacker

Reply #455
Great idea, FoxWolfie!

On a sidenote, although Mp3Packer might be up for the job as well, if implemented, I'm currently trying to find a program that can automatically extract images from the metadata and saves it as Folder.jpg IF there's none already in that folder, and removes them from the audio files afterwards. Does anyone know a program that can do this already?

Does this help???
http://vcardenasblog.blogspot.com/2008/09/...or-rockbox.html
You can run it on any folder...just sayin'


Yikes, that's one buggy program! It completely ignores anything I configure: even though I selected JPG output and Folder.jpg as filename (plus a size of 300x300 pixels), it exports BMPs of the original size (even though the embedded metadata was in PNG format, by the way). Think I have to get me a more reliable program to do the job. But thanks for the advice, though. Any other ideas?

@jimmanningjr: Thx, I use Mp3tag, so the whole removing part is not gonna be a problem then.

MP3 repacker

Reply #456
Great idea, FoxWolfie!

On a sidenote, although Mp3Packer might be up for the job as well, if implemented, I'm currently trying to find a program that can automatically extract images from the metadata and saves it as Folder.jpg IF there's none already in that folder, and removes them from the audio files afterwards. Does anyone know a program that can do this already?

Does this help???
http://vcardenasblog.blogspot.com/2008/09/...or-rockbox.html
You can run it on any folder...just sayin'


Yikes, that's one buggy program! It completely ignores anything I configure: even though I selected JPG output and Folder.jpg as filename (plus a size of 300x300 pixels), it exports BMPs of the original size (even though the embedded metadata was in PNG format, by the way). Think I have to get me a more reliable program to do the job. But thanks for the advice, though. Any other ideas?

@jimmanningjr: Thx, I use Mp3tag, so the whole removing part is not gonna be a problem then.

I am so sorry.    ..I would not recommend a program unless I thought it worked well...I have not had ANY of those problems. It worked like a charm.
I was using the 2.0 version I see he has recently updated to 2.1 maybe the newer one is buggy.
Here is a copy of the 2.0 version.. make sure you have both files (there are 2 files) in the same directory....good luck
It very odd because I set it for 300x300 .jpg and that is what i get. I had it do 25,000 tracks in less than 10 minutes.
I am running Windows 7 Ultimate off an OLD (2006)HP laptop w/ 4 gigs ram and 320 gig HD spinning at 5400rpm...
Good Luck and PLEASE let me know if you find something better.   
Jim Manning Jr.

 

MP3 repacker

Reply #457
I'm currently trying to find a program that can automatically extract images from the metadata and saves it as Folder.jpg IF there's none already in that folder, and removes them from the audio files afterwards.


I've run into few programs that would even view them, let alone extracting and removing them.  There are times when someone uploads entire albums with the same 60k image embedded in each of many tracks - a bit wasteful of space in my opinion.  One stand-alone jpg in a folder would be better than a dozen or more embedded inside the mp3s, where many players won't even see them.

If I want to keep an image from an mp3 file, I use a hex editor to select and save it.  The start of a jpg is FF D8 FF, and the end is FF D9. Note that the end signature of a jpg can occur within the body of the jpg too, so you have to watch what you're doing. I normally don't bother to keep embedded images though.

To remove the image from the mp3, you can usually just delete the entire ID3v2 tag for that file. Most of the time, the useful info fits into a ID3v1 tag anyway.  Removing *just* the image with a hex editor is not as easy, since you have to take into account the size offsets stored in the ID3V2 tag and recalculate them. A program could certainly be made to remove just the images, but the number of badly written ID3v2 tags out there would make it a challenge to create bug-free program. Removing the entire ID3v2 tag is easier. A program could simply copy as much as possible from the ID3v2 tag, into an ID3v1 tag, if one doesn't already exist, then kill the ID3v2 tag. This would effectively remove an image.
--
FoxWolfie

MP3 repacker

Reply #458
To remove the image from the mp3, you can usually just delete the entire ID3v2 tag for that file. Most of the time, the useful info fits into a ID3v1 tag anyway.

Sorry, but I have to strongly disagree here. I think this is a very bad advise. It's just not true, that the "useful" info will fit into the ID3v1 tag anyway. ID3v2 was conceived for a good reason, and that reason was that the original ID3 tag specifications are insufficient in many ways. If you delete the ID3v2 tags you will...

... get severely truncated song/artist/album fields (restricted to 30 characters length - will be enough for commercially short titled "hit singles", but on most serious albums you will get some truncated titles... are only the first 30 characters useful information!?)
... loose the total tracks/disc number fields (indispensable if you want to know if an album is actually complete)
... loose all the replaygain data (one of the greatest recent achievements in the field of digital audio)
... loose most of the genre information because ID3v1 is restricted to some preset types
... loose any additional tags which may contain usefull information about the releases

That said, it would be an insane undertaking to use a hex-editor to get rid of the embedded artwork. It's much faster and saver to use a tag editor like Mp3tag. Just drag the album into the tag editor, select all tracks, right-click, "Extended Tags...", then save the album art and remove it.

If you want to automate that procedure to apply it to your whole library that's no problem with Mp3tag either - just click on "Convert", "Actions", make a new action group named like "Save & remove embedded artwork", and add the actions "Export cover to file..." and "Remove fields" and type in "picture". Now drag your whole library into Mp3tag and apply that action. If you don't want to overwrite existing folder.jpg files, just use another name for export and than use a batch script to sort out the duplicates.

MP3 repacker

Reply #459
@Northpack: I totally agree with you on the importance of ID3v2, although it does allow for a lot of rogue field names. Overall consistency is a big problem in a large collection of MP3's.

I did not know that the customizability of the actions in mp3tag goes this far, I should've examined that beforehand, but thank you so much for the info, that'll help me to do exactly what I wanted to do!

MP3 repacker

Reply #460
@ Northpack
Took the words right out of my mouth...ID3v2 was made for a GOOD reason..ID3v1 was NOT up to snuff....I am a big fan of MP3TAG but I too did not know it was that customizable ...I hate to be a pest but could you post a Step byStep for doing this :make a new action group named like "Save & remove embedded artwork", and add the actions "Export cover to file..." and "Remove fields" and type in "picture". I would really like to have this option...Thank You in advance,Jim
PS. I would have no idea how to HEX EDIT Anythng..Im just not that far yet  Sounds VERY tedious and time consuming This is why we have tools W/ GUI !!!

MP3 repacker

Reply #461
That said, it would be an insane undertaking to use a hex-editor to get rid of the embedded artwork. It's much faster and saver to use a tag editor like Mp3tag. Just drag the album into the tag editor, select all tracks, right-click, "Extended Tags...", then save the album art and remove it.


As I said, I don't often have need to keep the art, so I never searched hard for a program to make it easier, When I do wish to save the art, it takes only a few seconds to spot the start of an image and jump to the end to save it. Sure, a program would be a bit faster, but not a big deal for something I might do a handful of times in a year. I normally just delete the annoyingly wasteful images. I certainly don't need or want 20 photos of an album cover with each 20 track album.  I also don't need a title and artist name stored twice inside each file, in addition to the filename and folder also containing much of that same info.  I don't need to look in an mp3 tag to know how many total tracks there are, when I can already see all of them in my playlist or in my file manager.

As for the ID3v1 holding most of the important data, I did say most of the time, not all of the time. I have around 15,000 mp3 files, and perhaps 1 to 3 percent of them have data I value that won't fit comfortably into a v1 tag.  In those cases, I can either keep the v2 tag, or verify that the mp3 filename, and the folder it is in, contains the wanted information.  If you have mp3s with extra data in them that you don't wish to lose, then don't delete the v2 tags. It's as simple as that.  Our needs are obviously different.  I prefer to strip my v2 tags when they contain nothing I need beyond what a v1 tag can hold. I think everyone is the best judge of their own files.  It's not as if I'm downloading files, stripping tags, re-uploading them, and forcing people to live with it. I'm stripping tags from files in my own archives only. It is just one way of getting rid of embedded images, for people who don't need the tags of course.
--
FoxWolfie

MP3 repacker

Reply #462
I hate to be a pest but could you post a Step byStep for doing this ...

Well, I don't know what you expect... what you quoted from me is actually a step-by-step guide

As I said, I don't often have need to keep the art, so I never searched hard for a program to make it easier, When I do wish to save the art, it takes only a few seconds to spot the start of an image and jump to the end to save it.

For a 20 track album, you have to manually edit 20 files in the hex-editor. With Mp3Tag, it's just one click for 20 or 20.000 files.

Quote
I certainly don't need or want 20 photos of an album cover with each 20 track album.  I also don't need a title and artist name stored twice inside each file, in addition to the filename and folder also containing much of that same info.  I don't need to look in an mp3 tag to know how many total tracks there are, when I can already see all of them in my playlist or in my file manager.

You could have accidently deleted the last tracks or got an incomplete album from the start. You won't know. I see that the embedded cover art may be a minor waste of space, that's why I get rid of it too. It would be nitpicking however, to be concerned about the few bytes an ordinary ID3v2 takes up.

MP3 repacker

Reply #463
Guys,

Don't forget that this is a tool (the only one?) for optimization of the audio data in an mp3 file, not the meta data. And it is doing it's job perfectly. OTOH, there is a plenty of tag management software around, you can redirect your requests to them.

MP3 repacker

Reply #464
For a 20 track album, you have to manually edit 20 files in the hex-editor.


No I don't. You obviously didn't read or understand what I wrote. I'd only use a hex editor when I wanted to actually *keep* an image. Why would I want to keep 20 of the same image?  Normally, I don't want to keep any.  I usually download a higher quality screen-size image from the web anyway.  If I do want to keep one, it is only going to be one for an entire album, which is still uncommon.  I've always just gotten rid of the others by killing the ID3v2 tags, which was fast, and did as I wanted *most* of the time.  Now that I know about mp3tag, I'll certainly take a look at it. I'm sure it will make those times when I want to kill an image without killing the tag a little faster.  What you don't seem to understand is that I don't usually want to keep the v2 tags at all, even when they don't contain images. To me, they are second or third copies of the info I already have. The extra info in them is generally not important to me. When it is, I keep the tags.

You could have accidently deleted the last tracks or got an incomplete album from the start. You won't know.


But I do know. I check before I even download something, to see if it is complete. My connection speed is only 768kb/s, so I'm not about to go after things that are incomplete from the start. In the few cases where I don't check before downloading, I definitely check after, and before burning. If you are trusting the track ## of total to always be correct in the v2 tags, then you may easily have more unspotted incompletes than I do. I've seen that info being wrong in a fair number of albums. I double check everything before getting to the burning stage, and almost always before the downloading even starts. In all the years I've collected music, I've had only one accidental delete. It was discovered during the web verification I do prior to burning. I had to re-download part of an album that time.

Now, if someone else comes along and steals my collection, they may not know if things are complete, since most of the v2 tags are gone. But, I know they're complete. I put a lot of effort into making sure that my albums are complete, or clearly marked otherwise, and that I can easily find any song or album again. I keep a master index of every song I've every burned, with several levels of backup. That way, I can find any song I have in generally well under a minute.

mp3packer does a wonderful job. I never use the remove tag options with it though, as they remove too much. I always want to keep all ID3 tags, until I've had a chance to individually decide on them. Then, and only then, do I decide to delete or keep the v2 tag in a file. I would never mass delete ID3 tags. However, there has never been a time that I wanted to keep an ApeTag or a Lyrics tag, or any other non-mp3/non-ID3 data, so I would definitely mass delete that stuff.  That is why I requested an additional option to kill only the non-mp3 and non-ID3 data.  An option to kill the junk that sometimes beaksmp3s in older players,without hurting the ID3 tags.
--
FoxWolfie

MP3 repacker

Reply #465
Don't forget that this is a tool (the only one?) for optimization of the audio data in an mp3 file, not the meta data. And it is doing it's job perfectly. OTOH, there is a plenty of tag management software around, you can redirect your requests to them.

Exactly.  Let's please stay on topic.

MP3 repacker

Reply #466
I have a small problem with MP3 repacker

I had a VBR mp3 file, MPEG-1 layer 3, 124 kbps (ABR)

I used MP3 repacker to transform it into CBR, using latest version 1.21 and mp3packer.exe -t -s -z -b 192 filename.mp3 command string
(I used just mp3packer.exe  -b 192 filename.mp3 first time, but got the same problem).

Now, when I open the new MP3 (CBR) file in WinAmp (v.5.56), it reports the file is still ABR:

Payload Size: 7057449 bytes
Header found at: 626 bytes
Encoder Delay: 576, Zero Padding: 1728
Length: 294 seconds
MPEG-1 layer 3
192 kbps (ABR), 11257 frames
44100 Hz Joint Stereo
CRC: No, Copyrighted: No
Original: Yes, Emphasis: None

The header looks like this (hex):
FF FB B0 44 00 00 00 00 │ 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
00 00 00 00 49 6E 66 6F │ 00 00 00 0F 00 00 2B F9
00 6B B2 9B 00 02 05 07 │ 0A 0C 0F 11 14 17 19 1C
1E 21 23 26 28 2B 2E 30 │ 33 35 38 3A 3D 40 42 45
47 4A 4C 4F 51 54 57 59 │ 5C 5E 61 63 66 68 6B 6E
70 73 75 78 7A 7D 7F 82 │ 85 87 8A 8C 8F 91 94 97
99 9C 9E A1 A3 A6 A8 AB │ AE B0 B3 B5 B8 BA BD BF
C2 C5 C7 CA CC CF D1 D4 │ D7 D9 DC DE E1 E3 E6 E8
EB EE F0 F3 F5 F8 FA FD │ 00 00 00 39 4C 41 4D 45
33 2E 39 38 20 02 AA 00 │ 00 00 00 2E 52 00 00 14
80 24 06 C0 4E 00 00 80 │ 00 45 91 AD 19 9E F3 17
00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00

Then, if I cut away the first 626 bytes of the file (the first MP3 frame), WinAmp now finds the header at 0. And no longer reports the file as ABR:

Payload Size: 7057449 bytes
Header found at: 0 bytes
Length: 294 seconds
MPEG-1 layer 3
192 kbps, approx. 1406 frames
44100 Hz Joint Stereo
CRC: No, Copyrighted: No
Original: Yes, Emphasis: None

But also the number of frames has changed (was - 11257 frames, became - approx. 1406 frames).
Other program reported it was 11258 first time, and 11257 after I truncated the first frame

The header now looks like this (hex):

FF FB B0 64 00 0F F0 00 │ 00 69 00 00 00 08 00 00
0D 20 00 00 01 00 00 01 │ A4 00 00 00 20 00 00 34
80 00 00 04 6D 70 33 70 │ 61 63 6B 65 72 31 2E 32
31 2D 32 32 39 0A 6D 70 │ 33 70 61 63 6B 65 72 31
2E 32 31 2D 32 32 39 0A │ 6D 70 33 70 61 63 6B 65
72 31 2E 32 31 2D 32 32 │ 39 0A 6D 70 33 70 61 63
6B 65 72 31 2E 32 31 2D │ 32 32 39 0A 6D 70 33 70
61 63 6B 65 72 31 2E 32 │ 31 2D 32 32 39 0A 6D 70
33 70 61 63 6B 65 72 31 │ 2E 32 31 2D 32 32 39 0A
6D 70 33 70 61 63 6B 65 │ 72 31 2E 32 31 2D 32 32
39 0A 6D 70 33 70 61 63 │ 6B 65 72 31 2E 32 31 2D
32 32 39 0A 6D 70 33 70 │ 61 63 6B 65 72 31 2E 32
31 2D 32 32 39 0A 6D 70 │ 33 70 61 63 6B 65 72 31
2E 32 31 2D 32 32 39 0A │ 6D 70 33 70 61 63 6B 65
72 31 2E 32 31 2D 32 32 │ 39 0A 6D 70 33 70 61 63
6B 65 72 31 2E 32 31 2D │ 32 32 39 0A 6D 70 33 70

MY QUESTION IS: is this a WinAmp bug or MP3 repacker problem ???
I mean, that after conversion WinAmp reports the Header at 626 bytes (not 0) and reports that the file is 192 kbps (ABR) and not just 192 kbps ???

MP3 repacker

Reply #467
It could be that the file won't fit into entirely 192kbps frames. There is no way in mp3packer to force CBR since it doesn't know initially if it will all fit.

Post the results of "mp3packer -i filename.mp3". Toward the bottom it will list the minimum size for CBR. If that number is larger than 192kbps then the file that mp3packer produced was not VBR. Otherwise the problem may be somewhere in mp3packer.

About the Winamp disparity when removing the header:
If a file has a header then the player knows exactly how the file was created. Without the header the player has 2 options: pre-read the entire file or read a few frames and guess. I'm pretty sure that Winamp will only read a couple frames. If the file is almost all 192kbps frames but it changes at the end, then Winamp may have only seen 192kbps frames. In this case the information it returns will be inaccurate.
Also, I think that the header Winamp reports is the header for the first frame that actually contains audio data, not the location of the XING/LAME header. Cutting off the XING header will cause the audio data to start at offset 0, so that line is correct.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #468
1) Results from first file - the file which WinAmp detects as 192 kbps (ABR)
The first MP3 frame contains Info tag (it's content is given in my previous post as Hex dump)

INFO:
MPEG1 layer 3
11257 frames
44100 Hz
38.281250 frames per second
294.060408 seconds
7058075 bytes in file (192.017009 kbps)
7057449 bytes in MP3 frames (191.999978 kbps) = current bitrate
33110787 bits of payload data (112.598589 kbps)
4143802 bytes of payload data (112.733354 kbps)
39629 bits wasted from partially-full bytes (0.134765 kbps)
4549054 bytes of MP3 data (123.758354 kbps) = minimum bitrate possible
2508395 bytes of padding (68.241625 kbps)
626 bytes outside MP3 frames (0.017031 kbps)
0 sync errors
Bitrate distribution:
192: 690,10567
Largest frame uses 6375 bits = 797 bytes = 244.042969 kbps
Smallest bitrate for CBR is 192

2) Results from the file with the first frame (containing Info tag) removed.
This file is detected by WinAmp as 192 kbps, approx. 1406 frames

MPEG1 layer 3
11257 frames
44100 Hz
38.281250 frames per second
294.060408 seconds
7057449 bytes in file (191.999978 kbps)
7057449 bytes in MP3 frames (191.999978 kbps) = current bitrate
33110787 bits of payload data (112.598589 kbps)
4143802 bytes of payload data (112.733354 kbps)
39629 bits wasted from partially-full bytes (0.134765 kbps)
4549054 bytes of MP3 data (123.758354 kbps) = minimum bitrate possible
2508395 bytes of padding (68.241625 kbps)
0 bytes outside MP3 frames (0.000000 kbps)
0 sync errors
Bitrate distribution:
  192: 690,10567
Largest frame uses 6375 bits = 797 bytes = 244.042969 kbps
Smallest bitrate for CBR is 192

I only noticed the difference in the line which I highlighted with Bold

MP3 repacker

Reply #469
It looks like the problem stems from the data inside the LAME tag. The file was encoded with ABR, so that was what was in the initial LAME tag. mp3packer treats the LAME tag as information about how the file was encoded, so keeps it the same as the input file. What probably happened is that Winamp saw the ABR in the LAME header and reported that information.

I have no idea why Winamp would say that the number of frames would change so drastically on deleting the first frame. MP3s do not store their length or bitrate anywhere (except in the non-standard XING/LAME header) so it's possible that Winamp had to guess. Oddly enough, what it guessed is exactly 1/8 the actual number of frames (well, rounded to the nearest whole number). It sort of looks like Winamp mistook bits for bytes somewhere in the process.

In conclusion, it looks like Winamp is correctly reporting the encoding setting as opposed to actually checking the frames of the file. (technically CBR is a subset of ABR, so calling it ABR is true, but that's splitting hairs). So in the end, nothing's wrong
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #470
I am new to using MP3 repacker an I could use a little help. I started the program using the following, mp3packer -t -s i:\music h:\output several files were processed then I received the following error message that I don't understand, Fatal error: exception Invalid_argument("String.sub"). Can anyone tell me what the message means and how I should correct it?

Thanks

MP3 repacker

Reply #471
Does anyone have a mirror of version 1.21? Nobody ever thinks to rehost files that are only available on unreliable servers such as a personal machine hosted on a personal ADSL line.

MP3 repacker

Reply #472
Does anyone have a mirror of version 1.21?

Here: mp3packer-1.21.rar - 0.21MB (at zShare)

As a bonus, copy-paste this into an editor, adjust the path to mp3packer.exe as needed (don't forget to use double backslashes), and save it as Add 'Analyze with MP3packer' right-click.reg:

Code: [Select]
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\*\shell\Analyze with MP3packer]

[HKEY_CLASSES_ROOT\*\shell\Analyze with MP3packer\command]
@="cmd /T:1F /K C:\\apps\\MP3packer\\mp3packer.exe -i \"%1\""

After you run it once, you should be able to right-click on an mp3 file and choose Analyze with MP3packer from the context menu. If anyone knows the right way to make this context menu item only show up for mp3 files, let me know. I tried changing the '*' to '.mp3' or 'mp3file' or 'mpegfile', but none of those seemed to work.