MP3 repacker

Topic: MP3 repacker (Read 593294 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Reply #300 – 2007-05-25 05:19:14

Quote from: Jojo on 2007-05-24 23:10:21

I assume neither of the changes affect WinMP3Packer, so that I just have to replace the .exe?

Yup. There weren't any changes in the latest version that would affect winmp3packer. Well... it may not report the errors correctly, if there were any. I changed around the error reporting in 1.16, and I don't know how winmp3packer handles it.

Quote from: gottkaiser on 2007-05-25 01:54:37

Could you add a option to keep the time stamps of the old mp3 files?

It looks like I can easily add the option to change the last accessed and last modified times for the files, but to change the created time would require an external app.

What did you have in mind for using the original times? Would just changing the last modified time work?

MP3 repacker

Reply #301 – 2007-05-25 10:13:48

Quote from: Omion on 2007-05-25 05:19:14

It looks like I can easily add the option to change the last accessed and last modified times for the files, but to change the created time would require an external app.

What did you have in mind for using the original times? Would just changing the last modified time work?

If it is not possible to keep all the time stamps inclusive created time. Then it's all right.

Thanks for trying! :-)

MP3 repacker

Reply #302 – 2007-05-25 11:42:41

Quote from: gottkaiser on 2007-05-25 01:54:37

@Omion

Thanks for developing this great tool!

I can only second that. Wiki article anyone?

MP3 repacker

Reply #303 – 2007-05-25 18:15:19

Quote

The -z switch now does something with MPEG2 / MPEG2.5 files (should fix j7n's issue)

Thank you for the update, those -r -R switches look promising. It wasn't me who tried repacking MPEG 2, but another poster above (Martin F.).

MP3 repacker

Reply #304 – 2007-05-25 19:35:03

@Omion

I created a Wiki article. Maybe you can check it that it's ok like that.

MP3 repacker

Reply #305 – 2007-05-26 09:03:16

Would it be possible to add Unicode filename support?

MP3 repacker

Reply #306 – 2007-05-27 02:07:55

Quote from: decayed.cell on 2007-05-26 09:03:16

Would it be possible to add Unicode filename support?

Unfortunately, that's not easy to do. The problem is that the programming language I use (OCaml) has no idea what Unicode is, so it refuses to open Unicode files. I've been thinking of writing a patch around that, but it probably won't be fixed for a while.

That's one of the few things I really hate about OCaml (the other is lack of multi-processor support), and it looks like it won't be officially supported for a while...

MP3 repacker

Reply #307 – 2007-05-28 01:06:51

@decayed.cell
Using special characters in filenames is a very bad idea. You risk losing data. Ocaml is but a single example of non-Unicode aware software.

(1) I've encountered several files where Mp3Packer messes up non-mp3 data at the end (APETAGEX/ID3). How non-standard non-fb9 the APETAGEX might be, this should not happen. Here is one sample processed with v1.17, it has happened before with other versions. It would seem that mp3packer chokes on the repeated "ALBUM" for some reason. Copy the code blocks to notepad in order to view them properly.

Original tag:

Code: [Select]

00000000   41 50 45 54 41 47 45 58  D0 07 00 00 1C 01 00 00  08 00 00 00 00 00 00 A0  00 00 00 00 00 00 00 00   APETAGEXŠ                       
00000020   0C 00 00 00 00 00 00 00  54 69 74 6C 65 00 41 64  69 6F 73 20 4E 6F 6E 69  6E 6F 1D 00 00 00 00 00           Title Adios Nonino      
00000040   00 00 41 72 74 69 73 74  00 53 65 78 74 65 74 6F  20 4D 61 6A 6F 72 20 54  61 6E 67 6F 20 4F 72 63     Artist Sexteto Major Tango Orc
00000060   68 65 73 74 72 61 13 00  00 00 00 00 00 00 41 6C  62 75 6D 00 41 20 50 61  73 73 69 6F 6E 20 66 6F   hestra        Album A Passion fo
00000080   72 20 54 61 6E 67 6F 1F  00 00 00 00 00 00 00 41  4C 42 55 4D 32 00 41 75  74 68 65 6E 74 69 63 20   r Tango        ALBUM2 Authentic 
000000A0   54 61 6E 67 6F 73 20 66  72 6F 6D 20 41 72 67 65  6E 74 69 6E 61 0A 00 00  00 00 00 00 00 41 4C 42   Tangos from Argentina        ALB
000000C0   55 4D 44 41 54 45 00 31  39 39 34 2D 30 37 2D 31  39 0B 00 00 00 00 00 00  00 45 4E 47 49 4E 45 45   UMDATE 1994-07-19        ENGINEE
000000E0   52 00 4C 61 75 72 61 20  46 6F 6E 7A 6F 0E 00 00  00 00 00 00 00 50 52 4F  44 55 43 45 52 00 45 74   R Laura Fonzo        PRODUCER Et
00000100   74 6F 72 65 20 53 74 72  61 74 74 61 02 00 00 00  00 00 00 00 54 72 61 63  6B 00 31 38 41 50 45 54   tore Stratta        Track 18APET
00000120   41 47 45 58 D0 07 00 00  1C 01 00 00 08 00 00 00  00 00 00 80 00 00 00 00  00 00 00 00 54 41 47 41   AGEXŠ              €        TAGA
00000140   64 69 6F 73 20 4E 6F 6E  69 6E 6F 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 53 65 78   dios Nonino                  Sex
00000160   74 65 74 6F 20 4D 61 6A  6F 72 20 54 61 6E 67 6F  20 4F 72 63 68 65 73 74  72 61 00 41 20 50 61 73   teto Major Tango Orchestra A Pas
00000180   73 69 6F 6E 20 66 6F 72  20 54 61 6E 67 6F 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   sion for Tango                  
000001A0   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 12 FF                                          ˙

Bad tag:

Code: [Select]

00000000   41 50 45 54 41 47 45 58  D0 07 00 00 1C 01 00 00  08 00 00 00 00 00 00 A0  00 00 00 00 00 00 00 00   APETAGEXŠ                       
00000020   0C 00 00 00 00 00 00 00  54 69 74 6C 65 00 41 64  69 6F 73 20 4E 6F 6E 69  6E 6F 1D 00 00 00 00 00           Title Adios Nonino      
00000040   00 00 41 72 74 69 73 74  00 53 65 78 74 65 74 6F  20 4D 61 6A 6F 72 20 54  61 6E 67 6F 20 4F 72 63     Artist Sexteto Major Tango Orc
00000060   68 65 73 74 72 61 13 00  00 00 00 00 00 00 41 6C  62 75 6D 00 41 20 50 61  73 73 69 6F 6E 20 66 6F   hestra        Album A Passion fo
00000080   72 20 54 61 6E 67 6F 1F  00 00 00 00 00 00 00 41  4C 42 55 4D 32 00 41 75  74 68 65 6E 74 69 63 20   r Tango        ALBUM2 Authentic 
000000A0   54 61 6E 67 6F 73 20 66  72 6F 6D 20 41 72 67 65  61 20 46 6F 6E 7A 6F 0E  00 00 00 00 00 00 00 50   Tangos from Argea Fonzo        P
000000C0   52 4F 44 55 43 45 52 00  45 74 74 6F 72 65 20 53  74 72 61 74 74 61 02 00  00 00 00 00 00 00 54 72   RODUCER Ettore Stratta        Tr
000000E0   61 63 6B 00 31 38 41 50  45 54 41 47 45 58 D0 07  00 00 1C 01 00 00 08 00  00 00 00 00 00 80 00 00   ack 18APETAGEXŠ              €  
00000100   00 00 00 00 00 00 54 41  47 41 64 69 6F 73 20 4E  6F 6E 69 6E 6F 00 00 00  00 00 00 00 00 00 00 00         TAGAdios Nonino           
00000120   00 00 00 00 00 00 00 53  65 78 74 65 74 6F 20 4D  61 6A 6F 72 20 54 61 6E  67 6F 20 4F 72 63 68 65          Sexteto Major Tango Orche
00000140   73 74 72 61 00 41 20 50  61 73 73 69 6F 6E 20 66  6F 72 20 54 61 6E 67 6F  00 00 00 00 00 00 00 00   stra A Passion for Tango        
00000160   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                                   
00000180   00 00 00 00 12 FF                                                                                         ˙

(2) How about setting the process priority to low by default? The processing with Z takes a long time and the comp becomes pretty much unresponsive during this process.

MP3 repacker

Reply #308 – 2007-05-28 01:32:45

Quote from: j7n on 2007-05-28 01:06:51

I've encountered several files where Mp3Packer messes up non-mp3 data at the end (APETAGEX/ID3). How non-standard non-fb9 the APETAGEX might be, this should not happen. Here is one sample processed with v1.17, it has happened before with other versions. It would seem that mp3packer chokes on the repeated "ALBUM" for some reason. Code blocks require 1280*960 to view properly using the default style.

I don't think it's a problem in the tag itself. mp3packer doesn't care or know about tags at all. It just sees a bunch of stuff which isn't MP3 data and copies it over to the new file. It's more likely a problem in the last mp3 frame which is causing mp3packer to screw up the tag.

There is a problem with MP3 files which have the last frame cut off. If a tag is added to the end of one of these files, it will actually start in the middle of the last MP3 frame. mp3packer will then "optimize" the last frame and throw out the beginning of the tag (since it is non-audio data in an mp3 frame)

That doesn't quite look like what's happening here, but something's definitely screwing up.

Quote

How about setting the process priority to low by default? The processing with Z takes a long time and the comp becomes pretty much unresponsive during this process.

I'll look into it. OCaml doesn't have a way to do that in Windows, but I could hook it into a custom C function that would do it. It shouldn't be too hard (assuming I remember how to do that )

MP3 repacker

Reply #309 – 2007-05-28 17:39:04

I can upload the whole file, but it's copyrighted.

It's been encoded using LAME 3.91, with some frames at the beginning chopped off that produces buffer underflow. Last frame is ok.

MP3 repacker

Reply #310 – 2007-05-30 13:47:35

Hm, I have a problem with the newest version (1.17). For all versions prior to 1.17, when using the flag -b 192 (and no other flags) I had the final vbr file within 10 seconds. With version 1.17, it took 16 minutes for the same operation. MP3 file size was 80MB.

Is this a bug or a "feature", and why?

Edit: I checked the same operation but now with the flags: "-b 192 -R" - this resulted in the old, very fast process (10s instead of 16m) and the final file size was EXACTLY the same (for the very slow "-b 192" and the fast "-b 192 -R")

MP3 repacker

Reply #311 – 2007-05-30 20:29:15

@Ojay:

The new way is supposed to be a feature, but obviously 16 minutes is far too long for any feature. And yes, the file size is always identical (-r and -R don't change the frame sizes at all, just the location of the data within the frame).

The -r switch (enabled by default if you use -b) adds another frame queue. Usually, one of two things happens with this:
1. If the -b switch is larger than the average input bitrate, the extra queue will be very small (1-4 frames)
2. If the -b switch is smaller than the average input bitrate, the extra queue will average ~50 frames

For a nasty enough input file, it is technically possible for the extra queue to have to store every frame in the file, which is quite a bit for an 80MB file. And each new frame has to check every frame in that queue, so the time it takes is proportional to the square of the number of frames! I didn't think that would happen so I didn't code for it, but I suppose Murphy's Law has a firm grasp on mp3 assumptions

I'd like to take a look at the file, but obviously it would be difficult to email an 80MB file. So instead, run this program on the file, like this:

Code: [Select]

mp3reader problemfile.mp3 > output.txt

Then zip and email the output.txt file to me.

Thanks for the report!

MP3 repacker

Reply #312 – 2007-05-31 20:46:04

Could MP3 repacker process MPEG-1 layer 2 files?

MP3 repacker

Reply #313 – 2007-06-01 05:00:39

Quote from: nemoW on 2007-05-31 20:46:04

Could MP3 repacker process MPEG-1 layer 2 files?

Nope. It just does layer 3. There is very little demand for it, and even less documentation, so I didn't bother. Unfortunately, it would be fairly difficult to wedge in support for layer 2 files right now.

Also, I'm going over the LAME layer 2 decoder, and it looks like there's no side info like there is for layer 3. If that's the case, it would imply that I'd have to actually decode every frame to see how long the data is, which would be way too much work given the difference in popularity between layer 2 and layer 3.

MP3 repacker

Reply #314 – 2007-06-01 08:02:43

hi.

I see the tool has been up for quite a while, but I just discovered it now, so, for starters, congratulations for making such a nice tool.

Now, I would like to ask something that maybe is a bit stupid but I ought to.
I'm starting to check some old mp3's I have to rehaul them a bit (retaggin with more accurate data, maybe a rename, adding replaygain, and, of course, repacking it).
Normally I would take extra time to check that the decoded sound is identical to the original after repacking, because my music is important to me (obviously ), but it's pretty time consuming and heavy.
Since I haven't experienced the program to fuck up my music yet, I've put a little cheap batch file in my PATH for mp3packer with my preferred comandline options (wich include -z, and deleting the original upon successful repack), and that's what I tend to use.
You seem to put out new versions quite fast, and that's good, but it makes me feel uneasy as to if the version I'm using (1.17-171 right now, wich is the last, if no new one has been posted while I write this) can be considered stable and working right, because, of course, my much loved music would be in danger.

So, could you, as the coder of this great tool, say whether it's advisable (withing reasonable limits) to just use the last version, or is there some earlier version wich is considered safer?

MP3 repacker

Reply #315 – 2007-06-01 10:24:31

What's the compression ratio gain one can expect from running MP3packer 1.17 over 320 kbps CBR LAME 3.97 encodes, realistically speaking?

Edit: realistically speaking implies I know about the Can make --preset insane files up to 10% smaller front page claim

MP3 repacker

Reply #316 – 2007-06-01 11:28:11

Radorn, due to the reasons I wrote about a few posts above, consider tagging your files after they've been processed by Mp3Packer, since in some cases your tags might get corrupted. However, I've never encountered the program outputting corrupted MPEG data.

In my opinion, there is no need to test the safety of Mp3Packer on all your collection. Mp3Packer is by no means a magic wand. I'd use this tool only if

- In a hex editor I see many null, 0xFF or otherwise repeating patterns of data.
- I have cut my files disregarding the bit reservoir. (Some hardware devices don't like these.)

MP3 repacker

Reply #317 – 2007-06-01 14:56:40

Polar and j7n

I appreciate you reply to my post, but you haven't really answered y question, but questioned my need for such an answer.

My interest from this tool, and the use I make of it, is beyond the scope, I believe.
I'm aware (though I haven't experienced) of the tag corrupting thing, wich is logical if you think about it. I really didn't imply an ordered procedure when I enumerated the things I do to my files. It was just a list, so repacking is not necesarily the last step.
Also, I know that big space savings are rare, and normally you just get a few kb, maybe less. That's not a problem to me.

What I mean is you should not question my reasons (and assume they are due to a lack of knowledge) and just give the best answer possible to the question. Or do both thinks if you must, but at least do the real answering.
That gives people (me in this case) the oportunity to decide what to do with the information, instead of just mindlessly accepting what others think is best.

I don't pretend to sound like lecturing anyone, it's just that I use to ask uncommon things (common ones are already answered, aren't they) and getting to get this kind of replies instead of a real answer, which don't solve me anything.

So, in the end.
Is there a policy or recommendation about what version to use regarding it's reliability? reliability meaning it won't fuck your files up.

MP3 repacker

Reply #318 – 2007-06-01 15:01:35

Quote from: radorn on 2007-06-01 14:56:40

Polar and j7n

I appreciate you reply to my post, but you haven't really answered y question, but questioned my need for such an answer.

Well, to be entirely honest, my post wasn't quite meant as a reply to yours, but fwiw, you're welcome

MP3 repacker

Reply #319 – 2007-06-01 15:22:38

Quote from: Polar on 2007-06-01 15:01:35

Quote from: radorn on 2007-06-01 14:56:40
Polar and j7n

I appreciate you reply to my post, but you haven't really answered y question, but questioned my need for such an answer.
Well, to be entirely honest, my post wasn't quite meant as a reply to yours, but fwiw, you're welcome

Oh, haha, sorry. I assumed it was for me since it seemed to be so given the content, timing and lack of clear adressing. my apologies.

MP3 repacker

Reply #320 – 2007-06-01 16:21:30

Omion - one 'feature' that I don't like is the automatic 'fixing' of sync errors. So there is still an audible skip, but the errors are no longer reported as the frame has been repaired.

eg on this track (0:13) : http://www.archive.org/download/xgn014_-_s...nown_galaxy.mp3

Also, I'm not sure if this has been mentioned yet, but is it possible to have a feature which allows the automatic removal of digital silence from the start and end of each track?

Quote from: Polar on 2007-06-01 10:24:31

What's the compression ratio gain one can expect from running MP3packer 1.17 over 320 kbps CBR LAME 3.97 encodes, realistically speaking?

Edit: realistically speaking implies I know about the Can make --preset insane files up to 10% smaller front page claim

It depends on the bitrate, encoder, track etc. But I typically get around 1-5% size reduction. Non-lame encodes can often be reduced a little more than lame encodes. Occasionally I notice some reduction even with 128-192kbit/s tracks, but it depends on the track and the encoder used. Edit - this is with using the -z switch.

MP3 repacker

Reply #321 – 2007-06-01 21:39:06

I noticed that files that contain ID3v2 and APEv2 tags are identified as 160kbps, even though they are 320kbps CBR. Also, I tried to shrink some Lame 3.96 encoded files using 320kbps and regular Stereo (no Joint-Stereo) and although I used the -z switch, it only saved 3kbps. I've tried several files.

MP3 repacker

Reply #322 – 2007-06-02 00:50:47

Quote from: radorn on 2007-06-01 14:56:40

Is there a policy or recommendation about what version to use regarding it's reliability? reliability meaning it won't fuck your files up.

Simple. After packing the mp3s, use foobar to do a bit compare between the packed and the original. If they match, you're good.

MP3 repacker

Reply #323 – 2007-06-02 01:32:18

Quote from: gib on 2007-06-02 00:50:47

Quote from: radorn on 2007-06-01 14:56:40

Is there a policy or recommendation about what version to use regarding it's reliability? reliability meaning it won't fuck your files up.

Simple. After packing the mp3s, use foobar to do a bit compare between the packed and the original. If they match, you're good.

If you had read my posts you'd know I already knew and did that, but it gets a bit tiresome after a while you know, so that's one reason I'm asking this.

"Normally I would take extra time to check that the decoded sound is identical to the original after repacking, because my music is important to me (obviously ), but it's pretty time consuming and heavy."
That I said, which you didn't read. Also, I made a batch file for repacking and deleting backups if mp3packer thinks everything went OK. It saves time and clicks you know... but only if you have the certainty that your files aren't getting fubar in the process. So, I need to know, to decide whether or not to use that "script", among other things.

Please, someone, answer to my question, instead of giving me alternatives.
I know my way arround these things and can make decissions for myself, but for that I need information, as concise as posible, and that's what I'm asking for, nothing more, nothing less.
Would someone be kind enough to do that? I beg. (and, no, I'm not being sarcastic, even though it could seem so)

MP3 repacker

Reply #324 – 2007-06-02 05:23:41

Quote from: radorn on 2007-06-01 08:02:43

hi.

I see the tool has been up for quite a while, but I just discovered it now, so, for starters, congratulations for making such a nice tool.

Now, I would like to ask something that maybe is a bit stupid but I ought to.
I'm starting to check some old mp3's I have to rehaul them a bit (retaggin with more accurate data, maybe a rename, adding replaygain, and, of course, repacking it).
Normally I would take extra time to check that the decoded sound is identical to the original after repacking, because my music is important to me (obviously ), but it's pretty time consuming and heavy.
Since I haven't experienced the program to fuck up my music yet, I've put a little cheap batch file in my PATH for mp3packer with my preferred comandline options (wich include -z, and deleting the original upon successful repack), and that's what I tend to use.
You seem to put out new versions quite fast, and that's good, but it makes me feel uneasy as to if the version I'm using (1.17-171 right now, wich is the last, if no new one has been posted while I write this) can be considered stable and working right, because, of course, my much loved music would be in danger.

So, could you, as the coder of this great tool, say whether it's advisable (withing reasonable limits) to just use the last version, or is there some earlier version wich is considered safer?

Starting with the last question:
Currently, 1.16 or 1.17 are the best bet. They are functionally the same when not using the -z switch. If you are using the -z switch, 1.17 will give slightly higher compression at a fairly significant time increase (up to 40% longer). If you are worried about new features being less tested, you should stick with 1.16. Otherwise use 1.17. All previous builds are available here.

That being said, I don't remember any well-formed mp3 files that did not test exact (without using -z) since 0.10 over a year ago. In the interest of fairness, here are the current issues that can happen:

If the input file was part of an improperly-split file, the first few frames may be gone
Obviously, random data errors can cause confusion, perhaps making a non-bit-identical file depending on how broken frames are handled by the other program.
If the XING/LAME frame is somehow invalid, mp3packer will throw it out whereas Foobar will still use the invalid information. This may make Foobar think the new file is a tiny bit longer and therefore not bit-identical.
j7n just reported an issue where an invalid last frame would cause the tags to get screwed up. This doesn't affect the audio at all, though.
mp3packer will only think that a frame is valid if it has the same samplerate, CRC existance, channel mode, copyright, and emphasis. Input files which are merged from two other files which differ on these conditions may only have the first part copied. (the one exception is if the first frame is LAME/XING. Then that frame only needs to have the same samplerate as the rest)
When using the -z switch, mp3packer handles a certain type of overflow one way whereas another program may handle it a different way. The details are a bit obscure, but it has to be handled one way or another.

Note, again, that all of these issues are due to incorrectly-formed input files.

Quote from: Polar on 2007-06-01 10:24:31

What's the compression ratio gain one can expect from running MP3packer 1.17 over 320 kbps CBR LAME 3.97 encodes, realistically speaking?

Edit: realistically speaking implies I know about the Can make --preset insane files up to 10% smaller front page claim

Yeah... --preset insane won't compress that much as of 3.97, unless you're using -z and get extremely lucky I don't know any exact numbers, but I seem to remember it's generally in the 1-3% range. -z is maybe ~5%. I would be happy to be corrected on this point, though, if anybody else has done any other tests.

@Jojo:
What program are you using to identify the file? Was this the input or the output file that you checked?

Notice