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 603527 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

MP3 repacker

Reply #200 –
Omion, thanks for the quick update. To tell you the truth though the new mode throws various errors on a lot of the files I've got from other encoders, not just iTunes (1.10 not 1.11, haven't been able to download the new one yet). LAME files seem to work flawlessly across the board of course. Would you be open to me sending you a little love package?

MP3 repacker

Reply #201 –
@bukem:
Yeah. My server was having a fit. The mirror link should still have worked, though. Was it down too?

@Gnerma:
Try out 1.11 first. Then send me a few files that still give recompression errors.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #202 –
Omion, would you be so kind to implement someday one crazy wish of mine: to add (optionally) Lame tag to the output file even if there is no Lame tag in the input file?

MP3 repacker

Reply #203 –
@Omion

Yep, main link as also the mirror server were down, but not anymore  . Now I can do some test and let you know the results. Greetz.

MP3 repacker

Reply #204 –
To confirm: I couldn't access either this morning.
I'm on a horse.

MP3 repacker

Reply #205 –
The links are working now

Omion, possibly in the future, can you add an option that outputs an MP3 that does use CRCs. I know, not everyone needs it, but it would be useful.

MP3 repacker

Reply #206 –
1.12 is out.

The major change was supposed to be that -z also recompressed short blocks, but it didn't take off a single byte from my 450MiB test suite, so I disabled it. 

The only change that made it in was a suppression of warning messages if the error didn't do anything. This was the same error on the reading side as the iTunes error was on the writing side.

Quote from: Rain on
Omion, possibly in the future, can you add an option that outputs an MP3 that does use CRCs. I know, not everyone needs it, but it would be useful.

That's a solid maybe 
I don't think it will be worth it, but I'll look into it. If it's easy, I'll do it.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #207 –
@Omion

Ave and Congratulations to you Omion! I've just finished mp3packer 1.12 test against my file set, and found no problems so far. Realy Great Job Omion! Keep up good work!!!

MP3 repacker

Reply #208 –
I've just tested mp3repacker on some test files using the prescribed syntax, however my files all ended up larger than before. 
The original size was 133,031,780 bytes.  Final size after repacking was 133,034,692.  I didn't use any switches, just "mp3repacker.exe in.mp3 out.mp3"
Got the same results using the GUI.
Here's one of the files for example, it gains 208 bytes from using mp3packer:
http://rapidshare.de/files/37112648/04_Hora.mp3

And the resulting files claim to have a bitrate of 64kbps.

MP3 repacker

Reply #209 –
You need to use the -z switch riggits:

Original - 10,347,388
Default - 10,347,596
With -z - 8,812,548

MP3 repacker

Reply #210 –
Quote from: Gnerma on
You need to use the -z switch riggits:

Original - 10,347,388
Default - 10,347,596
With -z - 8,812,548


Thanks Gnerma, I just tried that before reading your post
The -z switch also fixes the 64kbps bitrate issue, writing the correct bitrate instead.

MP3 repacker

Reply #211 –
@Omion

Hi there! I've found another mp3 track  that crashes mp3packer v1.12. And it seems that it's negative padding problem again:

Code: [Select]
*** '01. was a bee - this is what you are.mp3'
INFO:
 MPEG1 layer 3
 2 frames
 44100 Hz
 38.281250 frames per second
 0.052245 seconds
 6551199 bytes in file (1003152.346875 kbps)
 784 bytes in MP3 frames (120.050000 kbps) = current bitrate
 7112 bits of payload data (136.128125 kbps)
 889 bytes of payload data (136.128125 kbps)
 0 bits wasted from partially-full bytes (0.000000 kbps)
 961 bytes of MP3 data (147.153125 kbps) = minimum bitrate possible
 -177 bytes of padding (-27.103125 kbps)
 6550415 bytes outside MP3 frames (1003032.296875 kbps)
 1 sync error
 Bitrate distribution:
   80: 0,1
  160: 1,0
 Largest frame uses 7112 bits = 889 bytes = 272.256250 kbps
 Smallest bitrate for CBR is 160

MP3 repacker

Reply #212 –
what the heck do you do to your MP3s, bukem?

MP3 repacker

Reply #213 –
Quote from: riggits on
I've just tested mp3repacker on some test files using the prescribed syntax, however my files all ended up larger than before.

Ah. That is the one time that mp3packer will make files larger. I think you'll notice that all the files have the same file size increase. (you tested 14 files, right?) This occurs when mp3packer is unable to pack anything, but it still needs to write the XING header.

I don't know what the encoder was, but it didn't write the actual size of the data in each frame, meaning that you need to use the -z switch to recreate each frame. I got a nice 15% decrease when I used the -z switch on your test file.


You did, however, find a minor bug in the XING frame writing. The problem with the bitrate was that there is a 64kbps frame holding the XING header, which says the file is CBR 320. I suppose whatever program you used to get the bitrate info just noticed the 64kbps frame said CBR, therefore it was CBR 64...

Unfortunately, there is no easy way around this. It will only happen if the output file is CBR without the use of the -b switch, which only happens if mp3packer didn't actually do anything (as in your case).

Basically, it won't be fixed. Since it only occurs when programs which don't fully understand the XING header try to get info on an mp3 that couldn't get repacked, it's not high on my priorities.

BTW, which program did you use to get the bitrate info?
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #214 –
Quote from: bukem on
@Omion

Hi there! I've found another mp3 track  that crashes mp3packer v1.12. And it seems that it's negative padding problem again:

Stop breaking my program! 

The problem is that the mp3 has two VBR headers: an XING header and a VBRI header. This in itself is not a problem, but both frames say they're simple stereo, whereas all the other frames are joint stereo.

I had fixed the problem with this happening to just XING frames, but mp3packer treats a VBRI frame as standard audio, then throws out the other frames because they have the wrong channel mode.

In this case, the negative padding is actually a symptom, not the cause. While searching for a frame with simple stereo, mp3packer stumbled across a series of bytes that just happened to look like a frame header (it wasn't, though) That series of bytes indicated an offset of 302 bytes, but only 125 bytes were available.

The resultant file starts halfway through the song precisely because of the bogus frame. mp3packer will save everything before the first frame and after the last frame, but will throw out anything between frames. It saw the last frame as being about halfway through the file, and threw out the first half of the song.


What I'll probably do is make a switch to ignore any differences that could indicate invalid frames (like channel configuration and CRC) This will result in a higher level of resilience toward problems like this, at the expence of the possibility of more garbage frames on actually damaged files.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2
 

MP3 repacker

Reply #215 –
@Omion

Sorry for that, but I realy do love to break mp3packer  . THE SWITCH you propose is a good solution I think. It'll solve the irritating bukem problem for sure 

Ps. I guess that you could even name it (THE SWITCH) after me .e.g -nomorebukem

MP3 repacker

Reply #216 –
Quote from: bukem on
@Omion

Sorry for that, but I realy do love to break mp3packer  . THE SWITCH you propose is a good solution I think. It'll solve the irritating bukem problem for sure 

Ps. I guess that you could even name it (THE SWITCH) after me .e.g -nomorebukem

Well, I decided to solve your problem a different way than using a new switch: ignore VBRI frames. When a VBRI frame is encountered, it is completely skipped over and its frame settings are not saved to the file. This will make the resultant file ~104 bytes smaller (wow!) and will stop breaking on Bukem's bizarre mp3s. 

I probably will also make a switch to be more lenient on the settings, but I'm working on another program right now so it may be a while.

So version 1.13 should work on any files that have the same problem (not too many, I presume...)

PS. I'll keep your naming suggestion in mind when I do implement it!
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #217 –
Great to see this program still being enhanced (or rather after bukem decides to test some files and breaks it! )

Have you had your website for a while now? - I must've missed it...

---

What other program you working on Omion?

MP3 repacker

Reply #218 –
Quote from: jaybeee on
Have you had your website for a while now? - I must've missed it...
I've had my web page since about July. It's got more than just mp3packer on it, though. I also have a bunch of CG pictures that I've made over the years, and some old 64-bit builds of x264.

Quote from: jaybeee on
What other program you working on Omion?
It's a secret 
Actually, it's a program that will do distributed video encoding with x264 over a network. It's pretty hard to get working, but it should be out in a week or two.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #219 –
I'm (ab)using mp3packer right now to pack CBR MP3s to a higher bitrate, just so I can fool a friend who thinks that "all 128kbps mp3s sound like shit and I can totally hear the diff between 128 and 192". I encoded one to 128kbps using LAME 3.98a6 and packed a copy to 192, then sent him both.

Now to wait for him to listen and see if he thinks the 192 sounds better...

MP3 repacker

Reply #220 –
Let's just hope that he doesn't read this.

MP3 repacker

Reply #221 –
I have (finally) released a new version of WinMP3Packer to handle some of the extra options in mp3packer.exe. The thread is here.

MP3 repacker

Reply #222 –
@Omion

You know, I love the program since the first 0.x versions
I enjoy a lot the new -z switch but these days I found a file that generated a bunch of warnings    (there were no warnings without -z switch).

Code: [Select]
*** '07 - Time Canon.mp3' -> '07 - Time Canon-vbr-z.mp3'

 0% done on frame 0
WARNING: bitstream error on frame 0
WARNING: bitstream error on frame 22
WARNING: bitstream error on frame 25
WARNING: bitstream error on frame 27
1% done on frame 33
WARNING: bitstream error on frame 36
WARNING: bitstream error on frame 42
.
.
.
WARNING: bitstream error on frame 3520
ARNING: bitstream error on frame 3527
WARNING: bitstream error on frame 3536
WARNING: bitstream error on frame 3549
100% done with 3549 frames


This file was reportad as Xing(old) by EncSpot.
The -i switch produced the following output:
Code: [Select]
INFO:                                           
MPEG1 layer 3
3550 frames
44100 Hz
38.281250 frames per second
92.734694 seconds
2969600 bytes in file (256.180282 kbps)
2967511 bytes in MP3 frames (256.000069 kbps) = current bitrate
22716840 bits of payload data (244.965924 kbps)
2839605 bytes of payload data (244.965924 kbps)
0 bits wasted from partially-full bytes (0.000000 kbps)
2967405 bytes of MP3 data (255.990924 kbps) = minimum bitrate possible
106 bytes of padding (0.009144 kbps)
2089 bytes outside MP3 frames (0.180213 kbps)
0 sync errors
Bitrate distribution:
256: 289,3261
Largest frame uses 6608 bits = 826 bytes = 252.962500 kbps
Smallest bitrate for CBR is 256


Anyhow, a new vbr file was created and it seemed to be OK (checked again with -i switch).
I don't know if it's safe to use the new file though.
Well, I could live with it, it is just one file, but if you are interesting what caused the problems I could send it to you.
From my experience I know that the (ex)perl programmers don't have a rest untill the last issue is fixed .

Cheers
Tony

MP3 repacker

Reply #223 –
Quote from: Firon on
I'm (ab)using mp3packer right now to pack CBR MP3s to a higher bitrate, just so I can fool a friend who thinks that "all 128kbps mp3s sound like shit and I can totally hear the diff between 128 and 192". I encoded one to 128kbps using LAME 3.98a6 and packed a copy to 192, then sent him both.

Now to wait for him to listen and see if he thinks the 192 sounds better...
Heh. Keep us informed. This sounds interesting 

Quote from: Antonski on
@Omion

You know, I love the program since the first 0.x versions
I enjoy a lot the new -z switch but these days I found a file that generated a bunch of warnings    (there were no warnings without -z switch).

...

Anyhow, a new vbr file was created and it seemed to be OK (checked again with -i switch).
I don't know if it's safe to use the new file though.
Well, I could live with it, it is just one file, but if you are interesting what caused the problems I could send it to you.
From my experience I know that the (ex)perl programmers don't have a rest untill the last issue is fixed .

Cheers
Tony
Well, to tell the truth, all those warnings are fairly benign. I've been thinking about removing it altogether, because they don't really mean much.

If you get any warnings that say "WARNING: error recompressing frame x" then that means mp3packer did something bad. The bitstream errors just mean that the encoder cut a few too many corners.

In each frame of an MP3, there are 576 frequency bands, but some encoders go a little overboard and encode 578. In 1.12 I supressed the warnings when those extra bands were 0, but some encoders actually want to put data up there... all the decoders just throw the last 2 out, and mp3packer does too, but it outputs a warning each time it happens.

Quieting the error is on my list for the next version, but my video encoding proggie comes first.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #224 –
^^ rather than "Quieting the errors" how about turning "off" the display of them by default, but allowing a user, via a switch, to have them turned on?