HydrogenAudio

Lossy Audio Compression => MP3 => MP3 - Tech => Topic started by: Omion on 2005-03-15 01:33:03

Title: MP3 repacker
Post by: Omion on 2005-03-15 01:33:03
What it does:
Attempts to save space by storing frame data in the smallest possible frame. Usually MP3s are already stored in the most efficient way possible. However, for high-bitrate CBR files (like --preset insane) there can be a lot of wasted space

psyllium has made a great Windows GUI for this program. The GUI thread is here (http://www.hydrogenaudio.org/forums/index.php?showtopic=40780&hl=). Many people will find it easier to use than the CLI, and it has a few more features too (recursive directory support, 2-pass CBR).

How to use:
Download this 7Z file (version 2.04) (http://omion.dyndns.org/mp3packer/mp3packer-2.04.7z) (mirror (http://dl.dropbox.com/u/5833814/mp3packer/mp3packer-2.04.7z))
Extract to a directory that makes sense.
Type "mp3packer in.mp3 out.mp3" to repack the in.mp3 file
OR see mp3packer.html included in the package (or available here (http://omion.dyndns.org/mp3packer/mp3packer.html)) for more options.
The source can be downloaded here (http://omion.dyndns.org/mp3packer/mp3packer-2.04_src.zip) (mirror (http://dl.dropbox.com/u/5833814/mp3packer/mp3packer-2.04_src.zip)).

Features:
* Can make --preset insane files up to 10% smaller LOSSLESSLY (depending on the LAME version used)
* Squeezes out all the padding it can from any MP3 (Will not produce a larger file, unless you use the -b switch or something goes wrong)
* Writes valid LAME/XING header for proper VBR seeking
* Many people also use this backwards, to losslessly turn VBR into larger CBR files to humor players which can't handle VBR
* Includes a brute-force compression optimization option as of 1.10 to further compress files
* Now supports Unicode file names and paths
* Support for encoding an entire directory of files
* Works on Windows, Linux, 64-bit Linux, Linux through WINE, and should work perfectly on any other platform with an OCaml port
* GPL, so anybody can tweak it as long as it stays GPL

A few caveats:
* The program will always output an MP3 that doesn't use CRCs, even if the input file uses CRC. This is primarily laziness on my part, but nobody really needs them, and it saves 600 bits per second... (it's a feature, not a bug!)
* The 32-bit version will not process files larger than 1GB. The 64-bit version has a much higher limitation (4EB) which is unlikely to be encountered.
* There seems to be an incompatibility with the multi-threaded repacking code and 32-bit Windows XP. If you run across an error, try adding "--workers 0" to the command line.

Changelog (click here!) (http://omion.dyndns.org/mp3packer/mp3packer.html#changelog)
Title: MP3 repacker
Post by: Lyx on 2005-03-15 01:44:56
what about gapless playback? Will anything in the headers which is required for gapless playback be damaged?

- Lyx
Title: MP3 repacker
Post by: Omion on 2005-03-15 03:02:29
Quote
what about gapless playback? Will anything in the headers which is required for gapless playback be damaged?

- Lyx
[a href="index.php?act=findpost&pid=282291"][{POST_SNAPBACK}][/a]

Nope. Gapless settings are in the LAME tag, which is saved to the new file. The only LAME tag settings which I change are the ones that actually change (file length, etc.) Everything else is saved.
Title: MP3 repacker
Post by: Jojo on 2005-03-15 18:18:37
that's some pretty pimp stuff...does it handle files other than LAME as well?
Title: MP3 repacker
Post by: Omion on 2005-03-15 19:29:11
Quote
that's some pretty pimp stuff...does it handle files other than LAME as well?
[a href="index.php?act=findpost&pid=282468"][{POST_SNAPBACK}][/a]

Yup. If it's an MP3, it's supported. LAME is just extra-supported as the program handles LAME/XING headers properly.

I just noticed that MPEG2 and 2.5 files are having some sort of problem. I'll see if I can fix it sometime today. [Edit: MPEG2 / 2.5 files are working correctly as of version 0.02.]
Title: MP3 repacker
Post by: Qest on 2005-03-15 20:05:51
Sounds pretty cool. I wouldn't have thought there'd be that much to squeeze out (I don't know much about mp3's), but if it works as well as you say it does (I'm'a have to see for my self ) and it doesn't damage playability I'm betting this will become quite the popular little app.

Thank you for all your hard work .
Title: MP3 repacker
Post by: Jebus on 2005-03-15 20:14:37
So, basically this program turns a CBR file into a VBR file, correct? Pointing newbies who don't understand/trust VBR might be interested in reading this!
Title: MP3 repacker
Post by: krmathis on 2005-03-15 20:54:10
Seems to work fine.
I just tested it on some random MP3 files and it shaved of a few kb of everyone of them.
Title: MP3 repacker
Post by: Omion on 2005-03-15 20:59:27
Quote
Sounds pretty cool. I wouldn't have thought there'd be that much to squeeze out (I don't know much about mp3's), but if it works as well as you say it does (I'm'a have to see for my self ) and it doesn't damage playability I'm betting this will become quite the popular little app.

Thank you for all your hard work .
[a href="index.php?act=findpost&pid=282493"][{POST_SNAPBACK}][/a]

Well, most of the time there isn't anything to squeeze out. But on some files, most notably high-bitrate CBR files, there can be quite a bit of dead space.

@solaris:
Do you know which encoder/settings were used for your test files?
Title: MP3 repacker
Post by: Omion on 2005-03-15 21:04:07
Quote
So, basically this program turns a CBR file into a VBR file, correct? Pointing newbies who don't understand/trust VBR might be interested in reading this!
[a href="index.php?act=findpost&pid=282495"][{POST_SNAPBACK}][/a]

Yes, although it would be slightly more accurate to say that it turns any MP3 into a VBR file.

... actually, there's still a possibility that the resultant file is CBR, but that's extremely unlikely. It would indicate that the input file didn't use the bit reservoir, which is quite bad for an encoder to do.

Hmm... I guess the most accurate way to characterize the program is:
* At every frame, it picks the smallest frame size which can hold all the data
or perhaps simply:
* In the resultant file, dependancy on the bit reservoir is minimized

Although both of these definitions can be invalidated if you use some of the command line options. It looks like my little Perl script is pretty hard to define
Title: MP3 repacker
Post by: moozooh on 2005-03-15 22:32:27
Binary, anyone?
Title: MP3 repacker
Post by: Klyith on 2005-03-15 23:31:05
Quote
Binary, anyone?

Perl = script language = no binaries.

Someone who knows both perl and something like C can translate, but bla why bother. Here (http://www.activestate.com/Products/ActivePerl/) is the perl to get for windows. Install it, and then:
Run "perl mp3packer.pl in.mp3 out.mp3" to repack OR run "perl mp3packer.pl -h" to see other options
Title: MP3 repacker
Post by: 2thumbs on 2005-03-15 23:43:19
Quote
Quote
Binary, anyone?

Perl = script language = no binaries.

Someone who knows both perl and something like C can translate, but bla why bother. Here (http://www.activestate.com/Products/ActivePerl/) is the perl to get for windows. Install it, and then:
Run "perl mp3packer.pl in.mp3 out.mp3" to repack OR run "perl mp3packer.pl -h" to see other options
[a href="index.php?act=findpost&pid=282556"][{POST_SNAPBACK}][/a]


Well, you could use perlcc. Won't be as easy in this case because of the module that needs to be included. So you'd need to build the shared library first.
Code: [Select]
perlcc -o mp3packer.so mp3.pm

Then convert the mp3packer.pl to C
Code: [Select]
perlcc -c mp3packer.pl

Then you can use gcc to compile the C code and statically link the library into it.
Code: [Select]
gcc mp3packer.C -O2 -o mp3packer -static -lmp3packer.so

I think... I'm a bit rusty 

Not sure if this would even result in usable output either.
Title: MP3 repacker
Post by: krmathis on 2005-03-16 08:05:37
Quote
@solaris:
Do you know which encoder/settings were used for your test files?
[a href="index.php?act=findpost&pid=282513"][{POST_SNAPBACK}][/a]

They are lame --alt-preset standard. But there are some times since I encoded them, so I`m a bit unsure what lame version I used (probably 3.90.2/3 and/or 3.96.1).
I have no cbr files to test it on.
Title: MP3 repacker
Post by: moozooh on 2005-03-18 06:28:44
Code: [Select]
C:\Files\progs\Lame stuff\mp3packer>perl mp3packer.pl 1.mp3 2.mp3
Constant name 'HASH(0x1832adc)' has invalid characters at mp3.pm line 16
BEGIN failed--compilation aborted at mp3.pm line 19.
Compilation failed in require at mp3packer.pl line 25.

C:\Files\progs\Lame stuff\mp3packer>perl mp3packer.pl -h
Constant name 'HASH(0x1832ae0)' has invalid characters at mp3.pm line 16
BEGIN failed--compilation aborted at mp3.pm line 19.
Compilation failed in require at mp3packer.pl line 25.

C:\Files\progs\Lame stuff\mp3packer>

Wtf.
I'm using ActivePerl as recommended by Klyith, what am I doing wrong?
Title: MP3 repacker
Post by: sven_Bent on 2005-03-18 06:35:20
couldn't this funktion be put into lame ? some thing like -repack
Title: MP3 repacker
Post by: sven_Bent on 2005-03-18 06:59:58
just tried this. Saved a couple of bytes.
However the output is NOT the same

I used winamp diskwrite plugin.
Ran crc32 and md5 check on the files and they did not match,
also the size of the 2 decoded wavs where not identical either.

and id3v2 tags are removed from the file.
Title: MP3 repacker
Post by: DreamTactix291 on 2005-03-18 07:03:58
The way I'd describe the output of the songs I tried this with is almost constand 320k stream with the occasional flicker which is a 256k frame.  Still pretty fun to play around with.
Title: MP3 repacker
Post by: smack on 2005-03-18 07:56:51
@Omion
Thanks for the great tool!


Quote
I used winamp diskwrite plugin.
Ran crc32 and md5 check on the files and they did not match,
also the size of the 2 decoded wavs where not identical either.

Is the wav from mp3packer shorter than the original? If so, it might be related to the last frame of the mp3 being truncated because of the removal of padding.
(just speculating, haven't tested mp3packer for myself, yet)

Omion, any idea?


Quote
and id3v2 tags are removed from the file.

Which saves another few bytes! Great feature for a packer, isn't it?
Title: MP3 repacker
Post by: kjoonlee on 2005-03-18 08:25:00
Quote
just tried this. Saved a couple of bytes.
However the output is NOT the same

I used winamp diskwrite plugin.
Ran crc32 and md5 check on the files and they did not match,
also the size of the 2 decoded wavs where not identical either.

and id3v2 tags are removed from the file.
[a href="index.php?act=findpost&pid=283214"][{POST_SNAPBACK}][/a]

If you were using LAME-encoded MP3s, did you use a gapless decoder?
Title: MP3 repacker
Post by: Omion on 2005-03-18 10:04:36
Quote
@Omion
Thanks for the great tool!


Quote
I used winamp diskwrite plugin.
Ran crc32 and md5 check on the files and they did not match,
also the size of the 2 decoded wavs where not identical either.

Is the wav from mp3packer shorter than the original? If so, it might be related to the last frame of the mp3 being truncated because of the removal of padding.
(just speculating, haven't tested mp3packer for myself, yet)
Omion, any idea?
Quote
and id3v2 tags are removed from the file.

Which saves another few bytes! Great feature for a packer, isn't it?
[a href="index.php?act=findpost&pid=283218"][{POST_SNAPBACK}][/a]

The file should have the exact same number of frames, with the same data in them, and the same gapless settings. If they're not, either the program's wrong or the decoder's not producing identical output. This may be the case if the decoder is using dithering, which will add random (not reproducible) noise.

@ sven_Bent:
If you have Foobar, run the "bit-compare tracks" function on the two files. If you don't have Foobar, then could you run the SAME mp3 through the Winamp diskwriter plugin twice, and see if they match up. (If they don't, then your output is dithering)

About the ID3V2 tags, the repacker doesn't save anything before the first valid MP3 frame. It only saves the non-MP3 data after the end. This means that some versions of the ID3v2 tag will not be stored. (I think 2.4 is stored at the end... ID3 tags are a mess...  )
Title: MP3 repacker
Post by: Omion on 2005-03-18 10:22:44
Quote
Code: [Select]
C:\Files\progs\Lame stuff\mp3packer>perl mp3packer.pl 1.mp3 2.mp3
Constant name 'HASH(0x1832adc)' has invalid characters at mp3.pm line 16
BEGIN failed--compilation aborted at mp3.pm line 19.
Compilation failed in require at mp3packer.pl line 25.

C:\Files\progs\Lame stuff\mp3packer>perl mp3packer.pl -h
Constant name 'HASH(0x1832ae0)' has invalid characters at mp3.pm line 16
BEGIN failed--compilation aborted at mp3.pm line 19.
Compilation failed in require at mp3packer.pl line 25.

C:\Files\progs\Lame stuff\mp3packer>

Wtf.
I'm using ActivePerl as recommended by Klyith, what am I doing wrong?
[a href="index.php?act=findpost&pid=283209"][{POST_SNAPBACK}][/a]

What version of Perl are you using? Run "perl -v" and it should say something like "This is perl, v5.8.5 built for MSWin32-x86-multi-thread"

Line 16 is where the first constant is defined.
Try saving and running the following:
Code: [Select]
use constant {
    FOO => 'something',
    BAR => 3,
    BAZ => [1,2,3],
};
print "FOO: ", FOO, "\nBAR: ", BAR, "\nBAZ: ", BAZ, "\n";


The result should be something like:
Code: [Select]
FOO: something
BAR: 3
BAZ: ARRAY(0x182bc58)
(The array might have a different value)

If that doesn't run, then it looks like your "constant" library is screwed up... If it does run, then I'll have to try it out with ActivePerl, and see why my it doesn't like mp3packer.

I'm going to my parent's house tomorrow for a week, so I might not be as responsive as I should be, but I'll work on this as soon as I get things set up there.
Title: MP3 repacker
Post by: sven_Bent on 2005-03-18 21:29:18
@ominion

i dont have fobar her
but i did two diskwrites of the same mp3 as before (the original and not the repackwd)
and they came out bit identical

MD5
b526274595bd1b40fa744673c8b25f08 *first.wav
b526274595bd1b40fa744673c8b25f08 *Second.wav

CRC32
first.wav 75FDC377
Second.wav 75FDC377

So it definatly seems like the repack stuff is NOT lossless to the decoded stream
Title: MP3 repacker
Post by: Lyx on 2005-03-18 21:40:15
edit: nevermind - i misunderstood something.
Title: MP3 repacker
Post by: Omion on 2005-03-19 04:10:44
Quote
Code: [Select]
C:\Files\progs\Lame stuff\mp3packer>perl mp3packer.pl 1.mp3 2.mp3
Constant name 'HASH(0x1832adc)' has invalid characters at mp3.pm line 16
BEGIN failed--compilation aborted at mp3.pm line 19.
Compilation failed in require at mp3packer.pl line 25.

C:\Files\progs\Lame stuff\mp3packer>perl mp3packer.pl -h
Constant name 'HASH(0x1832ae0)' has invalid characters at mp3.pm line 16
BEGIN failed--compilation aborted at mp3.pm line 19.
Compilation failed in require at mp3packer.pl line 25.

C:\Files\progs\Lame stuff\mp3packer>

Wtf.
I'm using ActivePerl as recommended by Klyith, what am I doing wrong?
[a href="index.php?act=findpost&pid=283209"][{POST_SNAPBACK}][/a]

I think I know the problem. Some versions of Perl don't allow multiple constants to be defined at the same time. It should be fairly easy to fix... I'll do it as soon as I can. [Edit: Should be fixed now. Download version 0.02 and try it out.]
Title: MP3 repacker
Post by: Omion on 2005-03-20 02:29:01
Quote
@ominion

i dont have fobar her
but i did two diskwrites of the same mp3 as before (the original and not the repackwd)
and they came out bit identical

MD5
b526274595bd1b40fa744673c8b25f08 *first.wav
b526274595bd1b40fa744673c8b25f08 *Second.wav

CRC32
first.wav 75FDC377
Second.wav 75FDC377

So it definatly seems like the repack stuff is NOT lossless to the decoded stream
[a href="index.php?act=findpost&pid=283412"][{POST_SNAPBACK}][/a]

I figured it out. It's actually probably Winamp's fault. My program outputs a VBR stream, and so adds a VBR header at the front. This header is designed such that programs which don't support it will simply see an empty frame.

Winamp suppports the header, but it still plays the frame as an empty frame. Therefore, Winamp will add an extra 1152 null samples to a file with a VBR header. If the input file to mp3packer doesn't have a header, then Winamp will add an extra 1152 samples to the output file (which always has a header), thus making the MD5 different for the decoded files.

At least, I think that's how Winamp works. Foobar thinks my two test files are exactly the same, whereas Winamp outputs files with different MD5s.

In order to make sure, I took the two Winamp output files, deleted the WAV headers of the 2 (because the files have a different number of samples, which is encoded in the header) then deleted the first 1152 samples (4608 bytes) of the file from my program. The resulting files had the same MD5. That indicates that Winamp's output is the exact same, except for 1152 samples added to the front. If that makes any sense...
Title: MP3 repacker
Post by: moozooh on 2005-03-20 11:43:46
Okay, version 0.02 works. But still with some issues…

Code: [Select]
C:\Files\progs\Lame stuff\mp3packer>perl -v

This is perl, v5.6.1 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2001, Larry Wall

<…>

Code: [Select]
C:\Files\progs\Lame stuff\mp3packer>perl mp3packer.pl ae01.mp3 ae01repacked.mp3
WARNING: Bit reservoir overflow on frame 8
WARNING: Bit reservoir overflow on frame 9
WARNING: Bit reservoir overflow on frame 10
WARNING: Bit reservoir overflow on frame 11
WARNING: Bit reservoir overflow on frame 12
WARNING: Bit reservoir overflow on frame 13
WARNING: Bit reservoir overflow on frame 14
WARNING: Bit reservoir overflow on frame 15
WARNING: Bit reservoir overflow on frame 16
On frame 18

ERROR! Found more data than could be encoded in one frame!
Frame number 17 uses 1214 bytes, of which 1170 bytes need to be stored in
the current frame. (Note that the max data stored in a frame is 1009)
Try increasing the additional reservoir (-a switch), currently 0.
(The additional reservoir must be from 0 to 511)

C:\Files\progs\Lame stuff\mp3packer>perl mp3packer.pl -a 511 ae01.mp3 ae01repacked.mp3

Here it does massive BR overflow on almost every frame then halts and writes this:

Code: [Select]
ERROR! Found more data than could be encoded in one frame!
Frame number 3064 uses 1257 bytes, of which 1062 bytes need to be stored in the current frame. (Note that the max data stored in a frame is 1009)
Try increasing the additional reservoir (-a switch), currently 511.
(The additional reservoir must be from 0 to 511)

The file was 9:23 track encoded (not by me though) in 256 kbps cbr (lame 3.91). Encspot doesn't report any problems.
What do I do now?
Title: MP3 repacker
Post by: Omion on 2005-03-20 22:33:11
Quote
Okay, version 0.02 works. But still with some issues…

Code: [Select]
C:\Files\progs\Lame stuff\mp3packer>perl mp3packer.pl -a 511 ae01.mp3 ae01repacked.mp3

Here it does massive BR overflow on almost every frame then halts and writes this:

Code: [Select]
ERROR! Found more data than could be encoded in one frame!
Frame number 3064 uses 1257 bytes, of which 1062 bytes need to be stored in the current frame. (Note that the max data stored in a frame is 1009)
Try increasing the additional reservoir (-a switch), currently 511.
(The additional reservoir must be from 0 to 511)

The file was 9:23 track encoded (not by me though) in 256 kbps cbr (lame 3.91). Encspot doesn't report any problems.
What do I do now?
[a href="index.php?act=findpost&pid=283852"][{POST_SNAPBACK}][/a]


Try increasing the -p switch. It's 100 by default. Use "mp3packer -a 256 -p 200". If THAT doesn't work, then I'll need to do something about my frame-too-big handling. I'll start working on a better solution now... The problem is that, with many LAME encodes (especially CBR 256 -- you picked the worst one) the file might require at least n bytes in the reservoir, but my program tries to minimize the amount of bytes in the bit reservoir, so many times there's fewer than n bytes, so the program panics.

Encspot wouldn't notice any problems in the input file, simply because there really aren't any problems. It's just the way my program handles (or fails to handle) some files.

I'm pretty sure I can do some sort of "pre-pass" on the file, log all the frames which are larger than 320kbps, and try to only pad the reservoir right before them. I'll get to work on it, but I have no idea when it'll be done.
Title: MP3 repacker
Post by: moozooh on 2005-03-22 19:55:11
It works now, but only with -p 250 or more, the result is just stripping a few kbps.
Edit: “A few” = 2-8 kbps (tested on 224-256-320 kbps files).
Title: MP3 repacker
Post by: Jojo on 2005-03-22 20:55:11
I haven't had the chance yet to give it a try...but is it true that CBR files will end up as VBR files?
Title: MP3 repacker
Post by: Omion on 2005-03-22 23:40:17
Quote
It works now, but only with -p 250 or more, the result is just stripping a few kbps.
Edit: “A few” = 2-8 kbps (tested on 224-256-320 kbps files).
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=284635")

Hmmm... Do you know what program made the files? In my experience with both LAME and the iTunes encoder, CBR 320 files go down to around 290. I can believe that 224 won't give much improvement, though. The lower the bitrate, the more the files actually need all of it.

Quote
I haven't had the chance yet to give it a try...but is it true that CBR files will end up as VBR files?
[a href="index.php?act=findpost&pid=284651"][{POST_SNAPBACK}][/a]

Yup. That's how it works. It uses the minimal size for each frame, which almost always results in a VBR file.  (Just like I said in post [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=32379&view=findpost&p=282515]#10[/url]  ) A valid LAME VBR header is written, so programs will handle it the same way as they do every VBR file, if that's what you're wondering.

By the way, I made a new version which intelligently figures out where padding needs to be placed, so you don't need to screw around with the -a and -p switches. The downside to this is it either has to read the file twice (goes almost half as fast) or store the entire file into memory (uses lots of memory) I'll post it once I finish testing it.
Title: MP3 repacker
Post by: Omion on 2005-03-25 03:36:53
Just released version 0.03. Now you no longer need to fiddle with the -a and -p switches (actually they aren't even supported any more). It shouldn't complain about not having enough bits in the bit reservoir again.

I do recommend that you use the -m switch, as it tends to go about twice as fast. It crams the entire file into memory, so it's not good for large files. For standard 1-song-per-file MP3s it's fairly safe to use -m.
Title: MP3 repacker
Post by: kevinsham on 2005-03-25 06:31:09
I get this error for one file

On frame 7435 of 7536 (98substr outside of string at mp3packer/mp3.pm line 996.

and the resulting mp3 has no header


Also, i find some 320kbps files that are not packed at all.
Title: MP3 repacker
Post by: Lyx on 2005-03-25 11:09:40
@Omion

Would it be possible to add a parameter to the m-switch where you can specify a value in megabytes. If the file is larger than the specified value, then it will not be loaded into memory, if it is smaller or equal then it will be loaded into memory. This could be useful for batch-repacking in the future when your tool becomes stable.

- Lyx
Title: MP3 repacker
Post by: Antonski on 2005-03-25 18:40:51
Quote
I get this error for one file

On frame 7435 of 7536 (98substr outside of string at mp3packer/mp3.pm line 996.

and the resulting mp3 has no header


Also, i find some 320kbps files that are not packed at all.
[a href="index.php?act=findpost&pid=285369"][{POST_SNAPBACK}][/a]


I also got the same error when I tried to re-pack a new-Xing vbr file (according to EncSpot).
However other 9 cbr files (also Xing, old and new) were repacked without errors.

BTW, I don't think that Perl is not a "real" programming language 
Title: MP3 repacker
Post by: djdance on 2005-03-26 05:03:19
Boys, please let me simply download .EXE without any compiling, well?
Would anybody likes to upload exe and put the link here?
Title: MP3 repacker
Post by: kjoonlee on 2005-03-26 05:39:44
Um, you don't need a repacker binary. Use perl to run it.
Title: MP3 repacker
Post by: Omion on 2005-03-26 07:20:39
Quote
Quote
I get this error for one file

On frame 7435 of 7536 (98substr outside of string at mp3packer/mp3.pm line 996.

and the resulting mp3 has no header


Also, i find some 320kbps files that are not packed at all.
[a href="index.php?act=findpost&pid=285369"][{POST_SNAPBACK}][/a]


I also got the same error when I tried to re-pack a new-Xing vbr file (according to EncSpot).
However other 9 cbr files (also Xing, old and new) were repacked without errors.

BTW, I don't think that Perl is not a "real" programming language 
[a href="index.php?act=findpost&pid=285522"][{POST_SNAPBACK}][/a]

THAT's not good. Looks like I've made more bugs than I've squashed with the lastest version. I may have missed something whilst re-reading the XING tag spec. Can either of you send, say, the first 1KB of the problem file to me? I've PMed you my email address.

Unfortunately, I don't know how most people cut up a file, so I can't tell you how to send the first 1KB, but I'm sure someone here does.  I use an old hex editor called "Hedit" which doesn't even exist any more, so it's not really of any use.

By the way, does this only happen with version 0.03, or does 0.02 do it too?
[edit:] Also, does the -m switch affect the problem? [/edit]

@Lyx:
Adding a cutoff value for the -m switch would not only be possible, it would be extremely easy and useful. I don't know why I didn't think of it before. I'll add it to the next version, along with the fix to this bug people are getting.
Title: MP3 repacker
Post by: kjoonlee on 2005-03-26 08:56:23
For chopping, I use dd from GNU coreutils.

dd if=input.mp3 of=chopped_file bs=1000 count=1

edit: If you're running Windows, MinGW (http://www.mingw.org/), Cygwin (http://www.cygwin.com/), or GnuWin32 (http://gnuwin32.sourceforge.net/) should let you run coreutils.
Title: MP3 repacker
Post by: moozooh on 2005-03-26 09:40:33
0.3 works good for me, thanks.
Title: MP3 repacker
Post by: Antonski on 2005-03-26 12:15:43
Quote
Can either of you send, say, the first 1KB of the problem file to me? I've PMed you my email address.


Sure, I'll send it in Monday (that file is on my office desktop).
Meanwhile I'll try to reproduce the problem on my home PC (if my wife allow me to go closer to the comp  )

BTW, the problem could be with that file and not with your program. I even don't remember where I have downloaded it from.

Tony
Title: MP3 repacker
Post by: Omion on 2005-03-30 00:04:55
Released version 0.04.

Hopefully the previous "substr outside of string" error has been fixed. Thanks, Antonski and kevinsham, for sending me the files that broke.

Also added a "-M" option, which has one argument. If the file size is smaller than the argument, in MiB, then the "-m" option is turned on. Otherwise, it's turned off.

There was another problem which may or may not have existed, but it definitely shouldn't exist any more. The calculation for the XING TOC was off by around 100 bytes, which may have caused the XING tag to overflow and corrupt the first frame on very small files.
Title: MP3 repacker
Post by: Antonski on 2005-04-16 21:32:01
Hi Reed,

I'm afraid I've encounered a new problem with repacker, this time workng on my old home sweet Win98SE. I have Active Perl 5.6.1.
After repacking of every file the program generates a message "Illegal division by zero at mp3.pm line 785." and there is no Xing header in the output file (as far as I can see).
There is no problem with Win2000 though.
If you are interested, I would send you the the headers of the original file and both outputs - correct and incorrect.

BTW, I really like that program a lot. And Perl

~Tony
Title: MP3 repacker
Post by: Omion on 2005-04-16 22:01:36
@Antonski -
Hmm.... That's where the program divides by the size of the output file. Maybe win98 doesn't update the size of open filehandles or something. Try replacing your mp3.pm with this one (http://people.ucsc.edu/~rswilson/carp/MP3.PM). If that doesn't work, then I'll have to think of something else.
Title: MP3 repacker
Post by: Antonski on 2005-04-16 22:32:45
Quote
Try replacing your mp3.pm with this one (http://people.ucsc.edu/~rswilson/carp/MP3.PM).


Works perfectly!
Thank you 
Title: MP3 repacker
Post by: Deep_Elem on 2005-04-17 19:46:12
I've been tinkering with v.0.04 using the latest version of Perl on Win XP. I'm getting pretty good results, even with 192 kbps CBR LAME files. But I have noticed two issues:

1. My original LAME files have proper LAME tags, but the new files have no LAME tags (so I am adding them manually via fb2k).

2. Encspot now reports the encoder used as Xing or Gogo but the original files are definitely LAME.
Title: MP3 repacker
Post by: Omion on 2005-04-18 00:32:45
1. That's weird. If the input files have LAME tags, the output files should too. Otherwise, a simple XING tag is added. What version of LAME do you have, and how did you check if the files have the tag? It's possible that my program thinks the tag is incorrectly formed, and so just stores a standard XING tag. (If it doesn't write an XING tag either, that's very bad)

2. Well, the audio data is the same, so it shouldn't matter. Encspot just sees that the files are arranged differently from what LAME usually does, and guesses something else. The quality is the same as the original. (Except if a LAME tag is written, in which case EncSpot parrots the encoder string)
Title: MP3 repacker
Post by: asonicboom on 2005-05-16 07:34:02
Sorry to resurrect this thread on my first post but I really do like MP3 Packer and had a few questions...

Omion I use your program on all my old --preset insane files to remove tags and in the process shave a few kbits off the filesize. Am I right in saying that it also strips off any "bad last frames" that it encounters (I think you confirmed this in an earlier post) ?

When I recently tried to repack a 192kbps CBR mp3 Encspot showed the outputted file as having 224, 256 or 320 kpbs bit rates for some frames. Is this possible ? Is the mechanism similar to:
Quote
If LAME decides a frame needs more then 320kbps, it will take the needed bits from the bit reservoir.... As of version 0.03, very large frames are identified early enough to pack the reservoir dynamically.

I sincerely hope you are still developing this great little proggie, batch processing and perhaps an executable and a GUI would be very welcome indeed  although I am perfecty content with the app in its current form (if anyone reading could compile MP3 Repacker into a stable binary or show me how to go about it I would be eternally grateful ). As it is I currently use Florian's amazing MP3Tag program with mp3repacker inserted as a tool like so:
Code: [Select]
 Name: MP3 Packer
Path: C:\WINDOWS\system32\cmd.exe
Parameter: /c "cd /d "E:\Backup\Programs\MP3 Packer\MP3 Packer v0.04" && perl mp3packer.pl -mst "%_path%" "%_folderpath%\%_filename%vbr.mp3""
with "for all selected files" ticked. Provided the user adjusts the absolute path to the two MP3 Packer files accordingly then it allows any number of mp3s in a directory to be packed to output files in the same folder but with vbr appended to the end of the filename by simply highlighting the mp3s, right clicking and selecting the MP3 Packer tool. This pseudo-batch processing comes in quite handy so I hope those instructions help anyone else in the same situation as me. Omion I was wondering if you could tell me if it's "safe" to run so many MP3 Packers concurrently ?

Lastly I was hoping you could tell me if you are aware of any bugs that would make running Mp3 Packer on all of my old unreplaceable mp3s a bad decision...

Thanks for all your hard work and effort 

--asonicboom
Title: MP3 repacker
Post by: Omion on 2005-05-17 10:02:39
Quote
Sorry to resurrect this thread on my first post but I really do like MP3 Packer and had a few questions...

Omion I use your program on all my old --preset insane files to remove tags and in the process shave a few kbits off the filesize. Am I right in saying that it also strips off any "bad last frames" that it encounters (I think you confirmed this in an earlier post) ?
If a bad last frame is encountered, it is simply added to the "non-MP3 junk at the end" category. That means that if you use the -s option the bad frame will be thrown out, otherwise it will be included but not optimized.
Quote
When I recently tried to repack a 192kbps CBR mp3 Encspot showed the outputted file as having 224, 256 or 320 kpbs bit rates for some frames. Is this possible ? Is the mechanism similar to:
Quote
If LAME decides a frame needs more then 320kbps, it will take the needed bits from the bit reservoir.... As of version 0.03, very large frames are identified early enough to pack the reservoir dynamically.
It is possible, expected, and happens quite a lot  . Due to the bit reservoir, the amount of data stored in an MP3 frame has very little relation to the bitrate of that frame. For example, here's a graph of a 192-CBR file. The red is the size of each frame (constant, of course) but the black dots are the actual amount of data in each frame. The blue is how many bits are in the reservoir per frame.
although I am perfecty content with the app in its current form (if anyone reading could compile MP3 Repacker into a stable binary or show me how to go about it I would be eternally grateful ).[/quote]I've been trying to figure out how to make binaries from Perl, but my Perl doesn't seem to want to.

I don't have any experience or desire to make a GUI for the program, but if you want to, feel free  .
Quote
As it is I currently use Florian's amazing MP3Tag program with mp3repacker inserted as a tool like so:
Code: [Select]
 Name: MP3 Packer
Path: C:\WINDOWS\system32\cmd.exe
Parameter: /c "cd /d "E:\Backup\Programs\MP3 Packer\MP3 Packer v0.04" && perl mp3packer.pl -mst "%_path%" "%_folderpath%\%_filename%vbr.mp3""
with "for all selected files" ticked. Provided the user adjusts the absolute path to the two MP3 Packer files accordingly then it allows any number of mp3s in a directory to be packed to output files in the same folder but with vbr appended to the end of the filename by simply highlighting the mp3s, right clicking and selecting the MP3 Packer tool. This pseudo-batch processing comes in quite handy so I hope those instructions help anyone else in the same situation as me. Omion I was wondering if you could tell me if it's "safe" to run so many MP3 Packers concurrently ?
As long as you don't have them writing to the same file, running multiple repackers in parallel isn't a problem. (If you do have them writing to the same file, they won't corrupt it; they'll just exit with a "permission denied" error)
Quote
Lastly I was hoping you could tell me if you are aware of any bugs that would make running Mp3 Packer on all of my old unreplaceable mp3s a bad decision...
I don't know of any bugs in the program; it seems fairly stable. However, if you want to extra assurance, you can run the input and output files through Foobar's "bit-compare files". If that says they're OK, then you can delete the old one. If it says they're different, then post to this thread, as it would indicate a bug.

Quote
Thanks for all your hard work and effort 

--asonicboom
[a href="index.php?act=findpost&pid=297982"][{POST_SNAPBACK}][/a]
Thank you for the feedback! It's good to know that people are using my program.

[edit from 7 years in the future: fixed the images to point to my current server]
Title: MP3 repacker
Post by: asonicboom on 2005-05-18 03:53:42
Thanks for replying so soon and so comprehensively Omion, your answers were very helpful  Again good work on making such a great little program.
Quote
If that says they're OK, then you can delete the old one. If it says they're different, then post to this thread, as it would indicate a bug.
Will do  Till then...

--asonicboom
Title: MP3 repacker
Post by: halb27 on 2005-11-07 14:56:33
Quote
... The red is the size of each frame (constant, of course) but the black dots are the actual amount of data in each frame. The blue is how many bits are in the reservoir per frame. ...
[a href="index.php?act=findpost&pid=298272"][{POST_SNAPBACK}][/a]

How did you produce this graph? Very interesting to me as I'm interested a lot in the maximum actual frame size producable by encoders especially Lame 3.90.3 api and -b320. You show already that actual frame size can be more than the size of a 320 kbps frame (minus frame header minus side info).
(I'm interested in differences between Lame 3.90.3 and 3.96.1/3.97b when using cbr320. There is some evidence that 3.90.3 cbr320 provides better quality. 3.96+ doesn't use bit reservoir which restricts actual frame size to the size of a 320 kbps frame minus frame header minus side info. 3.90.3 however does use the bit reservoir but it is unclear with which restriction concerning maximum actual frame size.)
Title: MP3 repacker
Post by: smack on 2005-11-08 10:44:57
Quote
How did you produce this graph?

Omion may have used his very own mp3repacker tool with some of the DEBUG options enabled to output the numbers. You can try that yourself, simply edit the file mp3.pm accordingly.

Quote
There is some evidence that 3.90.3 cbr320 provides better quality.

Keep that discussion out this thread, please.
(for other readers, there is a thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=37989) about halb27's search for the ultimate way to create "[...] a universally usable mp3 archive not needing any transcoding any more" - using very high bitrates)
Title: MP3 repacker
Post by: Omion on 2005-11-08 19:43:55
Quote
How did you produce this graph?

I made a Perl script which I use as a debugger for my repacker. It outputs a bunch of garbage about each frame, then makes a few Mathematica-readable lists. I then used Mathematica to create the graphs.

@smack: The debug options in mp3.pm do a similar thing, but they don't output a nice list. It's more of a random spamming  .

Quote
Very interesting to me as I'm interested a lot in the maximum actual frame size producable by encoders especially Lame 3.90.3 api and -b320. You show already that actual frame size can be more than the size of a 320 kbps frame (minus frame header minus side info).
(I'm interested in differences between Lame 3.90.3 and 3.96.1/3.97b when using cbr320. There is some evidence that 3.90.3 cbr320 provides better quality. 3.96+ doesn't use bit reservoir which restricts actual frame size to the size of a 320 kbps frame minus frame header minus side info. 3.90.3 however does use the bit reservoir but it is unclear with which restriction concerning maximum actual frame size.)
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=340246")

I don't know about the quality difference, but the fact that newer LAMEs don't use the reservoir for API is why I made the repacker in the first place.For every frame that is less than 320kbps, some space is wasted.

PS. The Perl script I used is [a href="http://people.ucsc.edu/~rswilson/other/mp3reader.pl]here[/url].
Title: MP3 repacker
Post by: halb27 on 2005-11-08 22:14:40
Quote
I don't know about the quality difference, but the fact that newer LAMEs don't use the reservoir for API is why I made the repacker in the first place.For every frame that is less than 320kbps, some space is wasted.
PS. The Perl script I used is here (http://people.ucsc.edu/~rswilson/other/mp3reader.pl).
[a href="index.php?act=findpost&pid=340552"][{POST_SNAPBACK}][/a]


Thank you very much. I think it will help me a lot.
Title: MP3 repacker
Post by: Firon on 2005-12-18 01:34:03
Hmm, I seem to be having a strange issue with the repacker.
I was trying to repack some 192kbps CBR files to see the actual frame sizes (not to save any space, I know it won't help) and make it look like nifty VBR files.
However, when I ran it through the repacker, it spit out this error:
ERROR: Can't run frame location on layer 1 or 2 data at mp3.pm line 936.

Not sure what could be causing it (since it's layer III according to foobar and everything else decodes 'em just fine...)
Well, I got the first 4KiB of the file and uploaded it. If you need a bigger clip, I can give you one.
http://firon.site.voila.fr/mp3clip.mp3 (http://firon.site.voila.fr/mp3clip.mp3)

I didn't encode these myself, but according to some data at the end of the file, it was made by LAME3.89 (beta)
Title: MP3 repacker
Post by: Omion on 2005-12-19 08:56:09
Very strange. I'll take a look. (and see if I still remember what I was thinking when I wrote that  )

[edit]
HA! That's hilarious! It looks like it's all ID3v2's fault... again. Whoever tagged this shoulda used the "unsynchronization" feature...

Short answer: delete (or otherwise mangle) the tag!

Long answer:
The MP3 header sync pattern is 0xFFF. (normally doesn't occur in text)
There is an ID3v2 tag at the beginning of the file. (so far, so good)
That tag uses UTF-16 encoding. (still good)
The Unicode strings all have a 16-bit Unicode "byte order mark" ("BOM", Unicode character U+FEFF)
However, it's little-endian UTF-16 so the character U+FEFF is encoded to the bytes 0xFFFE. (BIG problem)

Now, since the ID3 tag is before everything else in the file, my program scans it for the first sync header. It sees the 0xFFF from the Unicode BOM and parses it as a frame header.

The tag was parsed as an MP1 frame, and since I couldn't find anything on how MP1 or MP2 files store the data I just kill the program when one is encountered. (Nobody here uses MP1 anyway...)

This whole problem could have been avoided if whoever tagged the file used the ID3 unsynchronization scheme. That outputs a 0x00 byte after all 0xFF bytes to break up any false sync headers PRECISELY because of this problem.

Most other programs at least know how to skip over ID3 data, which is why no other programs fail on this. mp3repacker, however, has the attitude that if it ain't an MP3 frame it's junk  (and I don't plan on changing that)

So the problem came from a combination of things:
* The file uses an ID3v2 tag
* The tag does not use the feature that breaks up confusing bytes
* The tag uses the EXACT Unicode encoding that results in lots of 0xFFFE strings
* My program has no idea what a "tag" is, or how to skip one when it sees one

My debugger program gives this as output:
Code: [Select]
Get a bunch of data from the file
Begin reading at 0 - 4096
Found a possible header at 21 (21)
 MPEG1 Layer 1
 160 kbps
 48000 Hz
 Stereo
 CRC present
 Padded frame
 Frame length: 481
Found a possible header at 962 (962)
 MPEG1 Layer 3                            
 192 kbps                                
 44100 Hz                                
 Stereo                                  
 CRC present                              
 Frame length: 626          
Found a possible header at 1588 (1588)
 MPEG1 Layer 3
 192 kbps
 44100 Hz
 Stereo
 CRC present
 Padded frame
 Frame length: 627
Found a possible header at 2215 (2215)
 MPEG1 Layer 3
 192 kbps
 44100 Hz
 Stereo
 CRC present
 Padded frame
 Frame length: 627
Found a possible header at 2842 (2842)
 MPEG1 Layer 3
 192 kbps
 44100 Hz
 Stereo
 CRC present
 Padded frame
 Frame length: 627
Found a possible header at 3469 (3469)
 MPEG1 Layer 3
 192 kbps
 44100 Hz
 Stereo
 CRC present
 Padded frame
 Frame length: 627
No possible headers found
 And the end of the file has been reached!
bitrate={160,192,192,192,192,192};

bpf={3848,5008,5016,5016,5016,5016};

bitsused={,4142,4998,4716,4446,4328};

reservoir={,0,70,34,33,66};


The first frame is the one from the header, and you can see that it is different from all the rest.
Title: MP3 repacker
Post by: Firon on 2005-12-22 09:31:39
Well, the tags were made by foobar2000 (I'd retagged the files with it), so blame it I guess.
I use ID3v2 and ID3v1 for compatibility reasons.

I'm not sure what to do. Turn off the BOM and rewrite the tags? It's a lot of files so I can't really delete or mangle the tags.
Title: MP3 repacker
Post by: Omion on 2005-12-22 21:41:26
Which version of the ID3v2-wrinting component do you have? I just downloaded the 1.17 and it only writes the BOM if it's actually using non-ASCII characters. I noticed that the file you uploaded has no reason to be in Unicode, so getting the newest version of the component and re-saving the tag will help in this case.

I would recommend against disabling the BOM, as it looks like it's the only way a program can tell if the data is actually Unicode and it's technically required (*)

You have a few options:
1. Get version 1.17 of the ID3v2 component and hope you don't run into any Unicode
2. Don't use ID3v2 anymore (ID3v1 and APE tags are both OK)
3. Don't use mp3repacker! It probably won't help much on a CBR 192 file
4. Pester whoever made the Foobar ID3v2 component (probably Peter) to support one of the following:
[span style='font-size:8pt;line-height:100%'].[/span] a. Big-endian Unicode
[span style='font-size:8pt;line-height:100%'].[/span] b. Unsynchronization padding

Note that although #4 would be the best solution, it is the least likely to go through, as evidenced from the ID3v2 'about' box:
Quote
About ID3v2 tag support

You've got your ID3v2, now STFU

Good luck! 

(*) Also, my version puts up a hilarious warning message if you try to disable the BOM. So don't do it.
Title: MP3 repacker
Post by: Firon on 2005-12-22 23:15:26
I've got version 1.20, which I nabbed off kode54's site. Perhaps I'll bother him about #4 on IRC next time I see him
Anyway, I rolled back to 1.17, no more problems.  Thanks for the tip.

I don't expect the mp3repacker to really help on these particular CBR files, I mostly wanted to use it for fun (and to see what impact the bit reservoir has on so-called CBR files).

TAKE OFF EVERY 'BOM'!!
YOU KNOW WHAT YOU DOING?
Title: MP3 repacker
Post by: Merlin744 on 2006-01-15 03:38:57
I am really impressed by this program.  It converts so much faster than EAC.  I am proud of myself simply for figuring how to run PERL.  I wish I could contribute to to the cause for batch processing.  for now all I can do though is wait for someone really smart to save the day.
Title: MP3 repacker
Post by: Omion on 2006-01-15 06:44:17
Well, it converts faster than EAC because it doesn't really do anything  . All my program does is re-arrange the bytes in an MP3 file (and might throw out a few unused ones). Although I am also impressed at how fast it goes. Perl is not known for speed.

As for batch processing, asonicboom posted a way to use an external program to do batch processing in this post (http://www.hydrogenaudio.org/forums/index.php?showtopic=32379&view=findpost&p=297982). As for actually supporting it in my program, I might do something about it. I haven't programmed Perl for a while, so I'll have to dust off Ye Olde Camle Booke and see how best to support multiple files.

I can't work on it right now because I'm in the middle of an OCaml program, and using 2 programming languages at once just leads to confusion (and many, many bugs).
Title: MP3 repacker
Post by: Merlin744 on 2006-01-16 09:54:24
Quote
Well, it converts faster than EAC because it doesn't really do anything  . All my program does is re-arrange the bytes in an MP3 file (and might throw out a few unused ones). Although I am also impressed at how fast it goes. Perl is not known for speed.

As for batch processing, asonicboom posted a way to use an external program to do batch processing in this post (http://www.hydrogenaudio.org/forums/index.php?showtopic=32379&view=findpost&p=297982). As for actually supporting it in my program, I might do something about it. I haven't programmed Perl for a while, so I'll have to dust off Ye Olde Camle Booke and see how best to support multiple files.

I can't work on it right now because I'm in the middle of an OCaml program, and using 2 programming languages at once just leads to confusion (and many, many bugs).



over at poineerprodjforums they are telling everyone that the only way to convert a VBR mp3 to a CBR version (for use on the pioneer CDJ-200)  is if they que them all up in Easy CD Creator and do it all in there. 

I sooo want to chime in and say  You know what, not only is that slow as hell, but it's just flat out shitty!.  If only we had a system for batch-processing a list, or a directory mp3s; and  maybe even a GUI....  Oh boy, would I love to go over there and say SHOVE IT!!  WE FIGURED OUT A WORK-AROUND FOR YOUR DAMN MACHINES THAT DON'T SUPPORT VBRMP3!!!    [a href="index.php?act=findpost&pid=357223"][{POST_SNAPBACK}][/a]

for now I will check out asonicboom's method.  good job!  we'll get there some day.
Title: MP3 repacker
Post by: jaybeee on 2006-01-16 14:21:31
Code: [Select]
Name: MP3 Packer
Path: C:\WINDOWS\system32\cmd.exe
Parameter: /c "cd /d "E:\Backup\Programs\MP3 Packer\MP3 Packer v0.04" && perl mp3packer.pl -mst "%_path%" "%_folderpath%\%_filename%vbr.mp3""

What are the specifics for getting this 'inserted' into mp3tag?  I'd liek to do this, but a wee bit more info would be great.
Title: MP3 repacker
Post by: senab on 2006-01-16 19:44:49
jaybee:

Make sure you've got Omion's Perl tool in a permanent folder, and get the latest version of Mp3Tag (http://www.mp3tag.de/en/), install it and open it. Go Tools --> Options. Click on the last option in the tree menu 'Tools'.  Now click on the icon to the right on the text box. And enter this:

Name: MP3 Packer (or whatever you want)
Path: Navigate to C:\Windows\System32\cmd.exe
Parameter: /c "cd /d "C:\Program Files\Encoding\mp3repack" && perl mp3packer.pl -mst "%_path%" "%_folderpath%\%_filename%-vbr.mp3""

N.B Where mine says 'C:\Program Files\Encoding\mp3repack', just change it to whatever folder you've UnRared the MP3 Packer to.

And check 'For all Selected Files'. Press OK and come out of the menu.

Now change the directory (press CTRL+D) and navigate to a folder of mp3's you want to repack. Select the MP3's, right click on them, go Tools --> MP3 Packer. You'll then get loads of command line terminals come up. Just leave it until it's all finished.

Your new files will have -vbr at the end of the filename.


And thanks Omion, you've solved a problem for me or cutting MP3's gaplessly. Now thanks to Sebi's PCutMP3 and this tool, my MP3's play on my Karma without the faintest gap.
Title: MP3 repacker
Post by: Omion on 2006-01-16 20:34:09
Quote
And thanks Omion, you've solved a problem for me or cutting MP3's gaplessly. Now thanks to Sebi's PCutMP3 and this tool, my MP3's play on my Karma without the faintest gap.
[a href="index.php?act=findpost&pid=357647"][{POST_SNAPBACK}][/a]

That was a completely unintended benifit, but I suppose it works.  I find it kind of funny that I made the tool to turn CBR into VBR files, and now it seems that most people are using it the other way around!

About the batch processing: I think I'll make it so that if you give it a directory as input, it will process all the .mp3 files within it. Then it'll add a specified string to the end of the filenames, like "-vbr". I should have it ready for testing in a few days.
Title: MP3 repacker
Post by: senab on 2006-01-16 21:03:49
Quote
That was a completely unintended benifit, but I suppose it works.  I find it kind of funny that I made the tool to turn CBR into VBR files, and now it seems that most people are using it the other way around!


I do turn my CBR's into VBR 

The reason I use repacker is because when PCut (and I'm not bashing Sebi's prog here, it's superb) cut's CBR MP3's it actually makes them VBR (the first frame is smaller than the rest CBR bitrate) but doesn't put any Xing header on. This messes up my Karma as it can't figure out the length of the file and gapless playback using the Lame tag padding.

Your MP3 packer, aswell as shedding KB's off, makes the file completely VBR compliant meaning gapless playback works like a charm.

 

Batch processing sounds good too...
Title: MP3 repacker
Post by: jaybeee on 2006-01-16 21:12:38
Many thanks senab.  Works like a charm.

And thanks for the interesting tool Omion.  Just tried it on a 185,809kb 320kbps file and it got it down to a 183,263kb 316kbps file.  Not as much as I thought it might, but I'll play with some other files.  Mind you, 2.5mb ain't too bad is it.
Title: MP3 repacker
Post by: Omion on 2006-01-16 21:18:11
Quote
I do turn my CBR's into VBR  
[a href="index.php?act=findpost&pid=357668"][{POST_SNAPBACK}][/a]

Oh. Right. I knew that.  It's still not quite what I had in mind...

Batch processing is coming along nicely, but I need to get to work soon. Should be finished by tomorrow night.
Title: MP3 repacker
Post by: Omion on 2006-01-17 08:00:48
Quote
And thanks for the interesting tool Omion.  Just tried it on a 185,809kb 320kbps file and it got it down to a 183,263kb 316kbps file.  Not as much as I thought it might, but I'll play with some other files.  Mind you, 2.5mb ain't too bad is it.
[a href="index.php?act=findpost&pid=357669"][{POST_SNAPBACK}][/a]

Do you know what was used to encode it? What kind of music is it? I may have to revise my "~10% off" statement...

[ edit: Just did a big test of ~6 hours of music and I got the files 3% smaller. Time to change the claim on the front page... ]
Title: MP3 repacker
Post by: jaybeee on 2006-01-17 17:13:55
Quote
Do you know what was used to encode it? What kind of music is it? I may have to revise my "~10% off" statement...[a href="index.php?act=findpost&pid=357735"][{POST_SNAPBACK}][/a]

LAME 3.96 (according to Mr QM)
Hip-hop from DJ Yoda.
Title: MP3 repacker
Post by: Omion on 2006-01-18 06:46:57
Kay, 0.07's out, and adds full-directory processing.

Basically, if you specify a directory as the anput file, it will do all MP3s that are in it (NOT recursive).

By default, it will append "-vbr" to the filename right before the extension, so a.b.c.mp3 will turn into a.b.c-vbr.mp3. Change the appended string with the -a option.

Also, it will skip files which already have the appended string on them. So if you specify "-a monkeys" it will skip the file "lots_of_monkeys.mp3". The idea is that such files have already been processed. You can force processing of all files by using the -A option.

Use the -X option to delete files after they are processed. USE WITH CAUTION! Only do this if you trust me to not delete your music. (I wouldn't!  )


The batch processing is by no means perfect. If you cancel processing in the middle and re-run it, it will probably throw an error about "conflicting filenames". In this case. you will need to delete EITHER the previous output files OR the input files which have already benn successfully processed.

[edit]
Just realized, some options don't work when they probably should:
-f doesn't work with batch processing
-X doesn't work with single-file processing
(-a and -A don't work with single-file either, but they're not supposed to)
[/edit]

I think that's about all the warnings I can give out. Good luck! 



@jaybeee:
Hmm... I think I'll have to revise my statement about taking off ~10% from API files. Maybe my testing isn't extensive enough.
Title: MP3 repacker
Post by: Merlin744 on 2006-01-20 10:24:31
this is an amazing tool!! I think everyone is too busy converting their mp3s (which takes a lot less time now!) and actually playing the music in their player of choice to make posts about how pleased they are.  I expect my pioneer cdj-200 unit in the mail tomorrow, and if it plays all these files that I've converted to CBR from VBR.... you have no idea how happy I will be.  My grin will stretch from ear to ear, all day long.   

I am also super excited about the GUI for this program.  Makes it so easy! Now an even bigger range of folks can use your software.  I'm sure that some companies who sell mp3 cd players, or portable mp3 players... whatever... wish they had thought like this beforehand!  I'm sure there's money in a market like this.  You guys are so rad! 

  where would we be, on the internet- without long-distance collaberation and open-source software like this?  NOT FAR AT ALL!
Title: MP3 repacker
Post by: jaybeee on 2006-01-20 16:30:39
^^ I'm confused: I thought it made CBR files VBR, not the other way round.  At least it does with mine.
Title: MP3 repacker
Post by: Madrigal on 2006-01-20 16:46:40
Quote
^^ I'm confused: I thought it made CBR files VBR, not the other way round.  At least it does with mine.
Primarily, you are correct. According to Omion's initial post: "Also, using this program on VBR files, or anything below ~200kbps is probably useless."

The single exception I know of, is converting any file (including VBR) to 320k CBR:

perl mp3packer.pl -b320 infile.mp3 outfile.mp3

Regards,
Madrigal
Title: MP3 repacker
Post by: Omion on 2006-01-20 19:27:40
Quote
^^ I'm confused: I thought it made CBR files VBR, not the other way round.  At least it does with mine.
[a href="index.php?act=findpost&pid=358589"][{POST_SNAPBACK}][/a]

That's the main reason it exists. But as Madrigal says, by forcing the minimum bitrate to 320, you can turn any MP3 into CBR 320. The reason one would do this is to play an MP3 on something which only supports CBR, like, apparently, most MP3 DJ mixing thingies.

Also, ABR files may be able to be turned into CBR at a lower bitrate, but there's no easy way to find out what the lowest CBR bitrate is.

PS. I went on the Pioneer DJ forums to get some more information about this, and all I discovered was how very glad I am that HA exists. A choice quote:
Quote
VBR = not as good as CBR, even if you think you're saving space, you're sacking audio quality.
Title: MP3 repacker
Post by: Merlin744 on 2006-01-20 22:49:15
I was so sad when I first read that pioneer forum last week. 

now, I am sooooooo glad this thing works!! 

if it could deal with sub-folders inside of the main folder... that would be even better.  but now I'm just being picky
Title: MP3 repacker
Post by: psyllium on 2006-01-21 10:13:37
Quote
I was so sad when I first read that pioneer forum last week. 

now, I am sooooooo glad this thing works!! 

if it could deal with sub-folders inside of the main folder... that would be even better.  but now I'm just being picky
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=358645")


My GUI front-end for this script is available here: [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=40780]http://www.hydrogenaudio.org/forums/index....showtopic=40780[/url]
Features batch processing and folder recursion
Title: MP3 repacker
Post by: Omion on 2006-01-25 07:59:18
Just released 0.08. If you don't use the -b switch, you don't care 

Basically there was a discrepancy with handling of CBR files. psyllium noted that inputting a 128kbps file with the "-b 128" switch resulted in a VBR file, not the CBR one would expect. The vast majority of the frames were 128kbps, but ~1% were 160.

As a fix, 0.08 now assumes padded frames for valid bitrates, and unpadded frames for invalid ones. For example:
"-b 129" -> UNpadded 160
"-b 128" -> PADDED 128
"-b 127" -> UNpadded 128
"-b 126" -> UNpadded 128
"-b 113" -> UNpadded 128
"-b 112" -> PADDED 112
"-b 111" -> UNpadded 112
etc.

The problem was that the -b switch (before 0.08) assumed unpadded frames, so using "-b 128" REALLY meant "-b 127.706", which opened the door for a 160kbps frame to sneak through (remember that lowering the minimum bitrate tends to raise the maximum bitrate). Now using "-b 128" assumes padded frames, so turns into "-b 128.013". This is enough to guarantee a CBR128 file stays a CBR128 file, but at the expense of a little more wasted space (On the order of 1 bit per frame)
Title: MP3 repacker
Post by: robert on 2006-01-25 22:30:28
padding is only needed for CBR at 44.1, 22.05 or 11.025 kHz. it should be done such that the actual bitrate is always less or equal to the desired bitrate. you may look into the LAME sources or read about it in MPEG-Layer3 Bitstream Syntax and Decoding. You can find that document at Gabriel's "mp3-tech" site: http://www.mp3-tech.org/programmer/docs/96-05.pdf (http://www.mp3-tech.org/programmer/docs/96-05.pdf)
Title: MP3 repacker
Post by: psyllium on 2006-01-26 02:04:19
A new version, 0.3 beta, of WinMP3Packer has been released which caters for version 0.08 of mp3packer.pl.

Check the thread here (http://www.hydrogenaudio.org/forums/index.php?showtopic=40780)
Title: MP3 repacker
Post by: Omion on 2006-01-27 04:43:04
Released 0.09.

Better support for whole directories. Specifically, the -f switch now works on directories, and the -X switch works with single files. Plus, added support for an output directory.

The other addition is the -i switch, which should be of interest to psyllium. It outputs a whole bunch of info, then exits. An example of the output:
Code: [Select]
INFO:
 MPEG1 layer 3
 13963 frames
 44100 Hz
 38.28125 frames per second
 364.747755102041 seconds
 6582738 bytes in file (144.37896673351 kbps)
 6582123 bytes in MP3 frames (144.365477959608 kbps)
 6078362 bytes of payload data (133.316505228103 kbps)
 6581030 bytes of MP3 data (144.341505228103 kbps)
 1093 bytes of padding (0.023972731504691 kbps)
 615 bytes outside MP3 frames (0.0134887739024565 kbps)
 Bitrate distribution:
  032: 27,0
  040: 8,0
  048: 7,0
  056: 14,0
  064: 28,0
  080: 187,0
  096: 812,0
  112: 1976,0
  128: 3834,0
  160: 4810,0
  192: 2082,0
  224: 163,0
  256: 15,0
 Smallest bitrate for CBR is 192

The filst few lines should be self-explanatory. All the bitrates are calculated slightly differently:
1st bitrate: bytes in file / second. Includes the tags and non-frame data
2nd: This is the "normal" bitrate, consisting of all the frame data
3rd: The amount of MP3 payload data, without the header, side info, or padding
4th: Payload data + header + side info. This is the theoretical minimum bitrate that mp3packer can pack to.
5th and 6th: How much is used up by padding and non-MP3 data, respectively

Then comes the bitrate distribution: The number of unpadded, padded frames at each bitrate (The example file didn't use padded frames)

Then comes the really interesting part: It calculates the smallest possible CBR bitrate. Like the GUI's approach, it is calculated by iterating through the bitrates and seeing if they will produce a CBR file. However, everything happens in memory and is optimized for just printing out info, so it goes MUCH faster.
Title: MP3 repacker
Post by: psyllium on 2006-02-02 15:25:57
Quote
Then comes the really interesting part: It calculates the smallest possible CBR bitrate. Like the GUI's approach, it is calculated by iterating through the bitrates and seeing if they will produce a CBR file. However, everything happens in memory and is optimized for just printing out info, so it goes MUCH faster.
[a href="index.php?act=findpost&pid=360074"][{POST_SNAPBACK}][/a]


Sweet as dude  I'll add support for that when my brain returns from holidays... in a few days I reckon...
Title: MP3 repacker
Post by: jaybeee on 2006-02-08 21:01:09
Getting this error:
Code: [Select]
ERROR: Can't run frame location on layer 1 or 2 data at mp3.pm line 1094.


I've tried via both the GUI & commanline and same.  Ran a basic command of: 'mp3packer.pl -a -vbr'

Interestingly, the GUI shows this file as being 128kbps, whereas MRQ shows 320kbps FhG.

Any ideas?
Title: MP3 repacker
Post by: Omion on 2006-02-09 06:35:16
That sounds like what Firon's problem on post 55 (http://www.hydrogenaudio.org/forums/index.php?showtopic=32379&view=findpost&p=350854) was. The problem was Unicode tags before the real MP3 data that look like the beginning of an MP1 or MP2 frame.

Make a copy of the file, and strip the tags off the copy (using Foobar or whatever), then try running mp3packer on the copy. If it works, then the problem is a false sync header in the tag. If it still doesn't work, then it's something else
Title: MP3 repacker
Post by: kevinsham on 2006-02-12 07:10:26
I am constantly getting this error message:

Wide character in print at C:\mp3packer/mp3.pm line 866.

The output file does not show correct length in foobar.
Title: MP3 repacker
Post by: Omion on 2006-02-12 07:33:29
Hmmm... that's where the program writes the LAME header. I have a lot of chr(....) statements which could result in a Unicode character slipping by once in a while, although obviously it shouldn't.

What kind of files make this error? Are they massively long? What command line are you using (or are you using psylium's GUI)? Does the file play OK? What if you use Foobar's "fix mp3 header"? (I think that's enough questions for now  )
Title: MP3 repacker
Post by: UED77 on 2006-02-12 08:10:01
Omion, I love your program, but I've been having some problems with it.

One is a minor annoyance: assuming a is the original CBR 320kbps mp3 without any ID3 (or other) tags, and b is a VBR by mp3packer 0.09, b - a != 0, which, I assume, it should. I did these operations in Audacity. The differences are minor, and generally inaudible, but it's still not a straight line

The other one is a bigger problem: I tested a CBR 96kbps tag-free mp3 with mp3packer, and got a VBR that had the following properties:
I do not know what might cause these problems, as I have removed tags from my input files... So that's why I'm turning to you for help.

Thanks,

UED77
Title: MP3 repacker
Post by: Omion on 2006-02-12 08:51:21
Quote
Omion, I love your program, but I've been having some problems with it.

One is a minor annoyance: assuming a is the original CBR 320kbps mp3 without any ID3 (or other) tags, and b is a VBR by mp3packer 0.09, b - a != 0, which, I assume, it should. I did these operations in Audacity. The differences are minor, and generally inaudible, but it's still not a straight line


Does Audacity dither the audio? That would be the most obvious explanation. My program doesn't decode any of the data, so if it messed it up it would probably be a LOT more noticabe than "generally inaudible". It's just about impossible for mp3packer to change the data a little bit. It'll either be perfect, offset by a multiple of 1152, or complete garbage. Try Foobar's "bit-compare files" feature; I know it works (and doesn't dither).

Quote
The other one is a bigger problem: I tested a CBR 96kbps tag-free mp3 with mp3packer, and got a VBR that had the following properties:
  • The copy was 3456 samples "behind" the original file, meaning that every single sample was shifted 3 frames.
  • The copy omits last 2304 samples of the original file altogether, even if not using -s. (This also happened with the b-a test above).
  • Approximately the first two frames of the copy contain modifications to the actual waveform, distorting the audio data in those first ~50 ms.
[a href="index.php?act=findpost&pid=363660"][{POST_SNAPBACK}][/a]

That's a bit bizarre. Even if the program is misinterpreting the XING tag, it should still only be off by 1152 samples. It sounds like something in the file is confusing my proggie. What version of Perl do you have?
Title: MP3 repacker
Post by: kevinsham on 2006-02-12 09:11:23
It seems that mp3packer is chopping the file. See the following output for running mp3packer for multiple times.

C:\>mp3packer 5.mp3 5a.mp3
Pre-parsing frame 3836
On frame 3836 of 3836
Output file uses frame sizes from 32 to 320
3836 frames in 1520131 bytes

C:\>mp3packer 5a.mp3 5b.mp3
Pre-parsing frame 3825
On frame 3825 of 3825
Output file uses frame sizes from 32 to 320
3825 frames in 1519171 bytes

C:\>mp3packer 5b.mp3 5c.mp3
Pre-parsing frame 3815
On frame 3815 of 3815
Output file uses frame sizes from 32 to 320
3815 frames in 1518211 bytes

C:\>mp3packer 5c.mp3 5d.mp3
Pre-parsing frame 3805
On frame 3805 of 3805
Output file uses frame sizes from 32 to 320
3805 frames in 1517251 bytes
Title: MP3 repacker
Post by: Omion on 2006-02-12 09:34:45
Quote
It seems that mp3packer is chopping the file.
[a href="index.php?act=findpost&pid=363666"][{POST_SNAPBACK}][/a]

O_O
You're right. Looks like that started on version 0.08. What an odd thing for the program to be doing... testing...

[edit]
WOW. I must have been completely insane when I was working on 0.08.

FIX:
Un-comment line 804 of mp3.pm. Delete the initial "#" character at the beginning of the line:
Code: [Select]
#    print OUT mp3::purgeAllFrames(\%framesOut, $padding)


I broke the download link in the first post so nobody else downloads it. I'll release 0.10 as soon as I hammer out the other problems brought to light today. Unfortunately, I am quite tired right now, so I'll work on them in the morning.
Title: MP3 repacker
Post by: jaybeee on 2006-02-12 10:03:14
Quote
That sounds like what Firon's problem on post 55 (http://www.hydrogenaudio.org/forums/index.php?showtopic=32379&view=findpost&p=350854) was. The problem was Unicode tags before the real MP3 data that look like the beginning of an MP1 or MP2 frame.

Make a copy of the file, and strip the tags off the copy (using Foobar or whatever), then try running mp3packer on the copy. If it works, then the problem is a false sync header in the tag. If it still doesn't work, then it's something else
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=362922")

Sorry for not getting back earlier.
Thought I'd let you know the outcome since you'll be looking at v0.10 soon.

If I update any of the tags (actually deleted a couple) in foobar, then it works ok.  So, seems it's the same problem as you mentioned.  However, when I then run mp3packer I get this:

Command run: mp3packer.pl -M 40 -a -vbr

Output from mp3packer:
Code: [Select]
Processing file '1.mp3' (Source bitrate: 320)
Using in-memory processing.
Output file is CBR 320
11147 frames in 11648161 bytes
Finished processing file.


Foobar properties of 1.mp3:
Code: [Select]
bitrate = 320
channels = 2
samplerate = 44100
mp3_stereo_mode = joint stereo
codec = MP3
   --------------------
12838511 samples @ 44100Hz
(rounded samples : 12838392)
Length: 4:51.122


Foobar properties of 1-vbr.mp3:
Code: [Select]
enc_delay = 0
enc_padding = 0
mp3_accurate_length = yes
bitrate = 320
codec = MP3
channels = 2
samplerate = 44100
mp3_stereo_mode = joint stereo
   --------------------
12840815 samples @ 44100Hz
(rounded samples : 12840744)
Length: 4:51.174




All fine so far, but...
1-vbr.mp3 when put into mp3packer shows the file is 56kbps CBR!
1-vbr.mp3 is displayed as 56kbps CBR by [a href="http://www.softpointer.com/AudioShell.htm]AudioShell 1.1[/url] and the length as 27:43
1-vbr.mp3 is displayed as 56kbps CBR by Mr QuestionMan v0.701 and the length as 27:44
1-vbr.mp3 is displayed as 56kbps CBR by Mp3tag v2.35 and length as 27:52

Now, I'm not bothered about the differences in the lengths that different progs display, but obviously the 27mins'ish time is just not correct.  Also, the 56kbps is surely not correct.

Any ideas?

PM me if you want some more details about the file.
Title: MP3 repacker
Post by: kevinsham on 2006-02-12 10:25:31
Quote
Quote
It seems that mp3packer is chopping the file.
[a href="index.php?act=findpost&pid=363666"][{POST_SNAPBACK}][/a]

O_O
You're right. Looks like that started on version 0.08. What an odd thing for the program to be doing... testing...

[edit]
WOW. I must have been completely insane when I was working on 0.08.

FIX:
Un-comment line 804 of mp3.pm. Delete the initial "#" character at the beginning of the line:
Code: [Select]
#    print OUT mp3::purgeAllFrames(\%framesOut, $padding)


I broke the download link in the first post so nobody else downloads it. I'll release 0.10 as soon as I hammer out the other problems brought to light today. Unfortunately, I am quite tired right now, so I'll work on them in the morning.
[a href="index.php?act=findpost&pid=363671"][{POST_SNAPBACK}][/a]



This fix has a side effect: the line 866 error is gone too!
Title: MP3 repacker
Post by: UED77 on 2006-02-12 19:10:28
Okay, I commented out line 804, like you suggested. The cause of my first problem was probably Audacity's dithering, as foobar2000's bitcompare says the two files's outputs are identical -- albeit of different lengths. Commenting out the line fixes this problem.

As for the second problem issue, commenting out the line seems to fix this too.

Thanks for your help, and keep up the great work!

UED77
Title: MP3 repacker
Post by: Omion on 2006-02-12 20:02:19
Quote
Now, I'm not bothered about the differences in the lengths that different progs display, but obviously the 27mins'ish time is just not correct.  Also, the 56kbps is surely not correct.

Any ideas?

PM me if you want some more details about the file.
[a href="index.php?act=findpost&pid=363676"][{POST_SNAPBACK}][/a]

I think I might know the problem. mp3repacker uses a small frame for the XING header (unless the -b option is given) That space is reserved before the file is written. However, the file that you have was repacked to a CBR file, so the small XING frame says it's CBR. I guess programs see that and think it's actually 56kbps CBR. The problem that I see is that the frame is usually a 64kbps frame, so I don't really see why anything would mistake that as 56kbps.

The timing being off is another effect of the bitrate being completely wrong. 56/320 = 4:51/27:44. Fixing the bitrate will fix the timing.

I think I can make sure that the XING tag only says it's CBR if the initial frame is the same bitrate as the rest of them.


PS. What was the initial encoder? It looks like the encoder didn't use the bit reservoir, and just about completely filled up every frame. It's very rare for my program to output a CBR file without the use of the -b switch.
Title: MP3 repacker
Post by: jaybeee on 2006-02-12 20:19:56
Quote
PS. What was the initial encoder? It looks like the encoder didn't use the bit reservoir, and just about completely filled up every frame. It's very rare for my program to output a CBR file without the use of the -b switch.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=363775")
see post [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=32379&view=findpost&p=362831]post 83[/url] - FhG 

Thanks for looking at this btw
Title: MP3 repacker
Post by: Omion on 2006-02-13 08:27:09
0.10 out. Just a bugfix. All the recent gripes should be quelched
Title: MP3 repacker
Post by: jaybeee on 2006-02-13 10:16:15
Quote
0.10 out. Just a bugfix. All the recent gripes should be quelched
[a href="index.php?act=findpost&pid=363872"][{POST_SNAPBACK}][/a]

Many thanks Omion.

I reckon that for most peeps using your prog to reduce the size of files and thus make vbr files, it will be done on non-LAME mp3s.  Cos most peeps that use LAME will probably use vbr or cbr 192kbps.  Thus, the mp3 files might not be created in the nicest way... just like the file that I'm having problems with, and as you said yourself (via PM).  Just goes to show how good LAME really is.
Title: MP3 repacker
Post by: kevinsham on 2006-02-13 13:21:59
A feature request:
Rename the original file and use the input file name as output.
Title: MP3 repacker
Post by: jaybeee on 2006-02-13 13:28:16
Quote
A feature request:
Rename the original file and use the input file name as output.
[a href="index.php?act=findpost&pid=363922"][{POST_SNAPBACK}][/a]
Ah yes. 
As in: shove '-orig' on the end of the original input file, and thus the resulting output file can have the original's original name (follow me!?).
Title: MP3 repacker
Post by: MuncherOfSpleens on 2006-02-13 19:27:20
Hmm, when using this I get the error message "Can't locate object method 'close' via package 'mp3' (perhaps you forgot to load 'mp3'?) at mp3packer.pl line 171."  It will still work when just using the command prompt, but the frontend (http://www.hydrogenaudio.org/forums/index.php?showtopic=40780&hl=winmp3packer) will cancel the process (or something, it stops and deletes the output file).  I was hoping version 0.10 would fix this (I've only had trouble with version 0.9 and now 0.10).  Any idea what's wrong?
Title: MP3 repacker
Post by: Omion on 2006-02-13 19:46:22
So, the command line will put up that warning then keep going, whereas the GUI will put up the warning and die?

The most likely cause of it is that you have another mp3.pm on the path somewhere. I added the close method in version 0.07. Did you have another version before that?

[edit: didn't need to quote all that]
Title: MP3 repacker
Post by: MuncherOfSpleens on 2006-02-13 20:43:34
Aha, that seemed to fix it.  I had a few stray copies of mp3.pm around on my hard drive, and deleting them fixed the problem.
Title: MP3 repacker
Post by: crazychimp132 on 2006-02-15 04:44:09
I think it would be useful if somebody with all the components (perl, mp3.pm, the frontend, anything else this requires to run) could make available a zip or rar to download containing all of these. It would make it more convenient for those of us with nothing.
Title: MP3 repacker
Post by: TBO on 2006-02-15 16:14:36
Perl may be too big to include in such a package. Psyllium's frontend comes packaged with mp3packer.pl but he may not have updated it to the latest version yet. Either way, you shouldn't have too much work to do.
Title: MP3 repacker
Post by: UED77 on 2006-02-15 18:50:48
It wouldn't be wise to include Perl, but a link to the ActiveState download page from the first post would certainly be helpful to a lot of new users. The frontend is a separate project, and until that is updated, it's best to just replace the two perl files from this one and use them with the frontend.

UED77
Title: MP3 repacker
Post by: psyllium on 2006-02-16 10:31:50
I've just now updated the .zip package for WinMP3Packer to include version 0.10 of the script.
Title: MP3 repacker
Post by: TBO on 2006-02-16 17:41:04
Speaking of which...
Title: MP3 repacker
Post by: kwanbis on 2006-02-16 19:00:58
i think i have read this fixes the nano suttering problems? righ?
Title: MP3 repacker
Post by: Omion on 2006-02-17 02:00:33
Quote
i think i have read this fixes the nano suttering problems? righ?
[a href="index.php?act=findpost&pid=364776"][{POST_SNAPBACK}][/a]

Does it? I suppose if the problem actually is that it can't handle VBR correctly, then using the "unpack" to CBR mode would help. Howener, if the problem is that it doesn't handle high bitrate files, then mp3packer won't help a bit (the amount of data to process is always the same).

It'd be interesting if somebody tested it out and repored back.


As for including Perl, I'm sure it's possible, but the script depends on a couple of standard modules, which depend on a few more modules, etc. It'd be easier to compile an exe file out of it, and even that is pretty difficult.


Regarding the option to rename the original files, I think it's a good idea. However, I'll want to extend it so that it will work on directories as well (that is, it will move all the original files into a new directory) I'll tinker with that when I have the time.
Title: MP3 repacker
Post by: Firon on 2006-02-17 07:15:45
It should help in theory. I believe the problem was that the firmware wouldn't change change the CPU clockspeed fast enough to deal with the bitrate jumps.
Title: MP3 repacker
Post by: kwanbis on 2006-02-17 12:32:16
eactly, so, anyone with nanos can test it?
Title: MP3 repacker
Post by: [JAZ] on 2006-02-23 17:36:37
Mmmm.... is it me, or mp3 repacker doesn't maintain the encoder_delay and encoder_padding from the LAME header?

Prev:
Code: [Select]
enc_delay = 576
enc_padding = 2076
mp3_accurate_length = yes
bitrate = 320
codec = MP3
encoding = lossy
channels = 2
samplerate = 44100
mp3_stereo_mode = joint stereo
tagtype = apev2|id3v1
----------
9607332 samples @ 44100Hz
File size: 8 718 065 bytes


Post:
Code: [Select]
enc_delay = 0
enc_padding = 0
mp3_accurate_length = yes
bitrate = 320
codec = MP3
encoding = lossy
channels = 2
samplerate = 44100
extrainfo = VBR
mp3_stereo_mode = joint stereo
tagtype = apev2|id3v1
----------
9610607 samples @ 44100Hz
File size: 8 709 308 bytes



(Also... i got quite puzzled to see a 1/1000% saving :S this was a 3.90.3 --api )
Title: MP3 repacker
Post by: Omion on 2006-02-23 20:08:49
Quote
,Feb 23 2006, 10:36 AM]Mmmm.... is it me, or mp3 repacker doesn't maintain the encoder_delay and encoder_padding from the LAME header?

(Also... i got quite puzzled to see a 1/1000% saving :S this was a 3.90.3 --api )
[a href="index.php?act=findpost&pid=366620"][{POST_SNAPBACK}][/a]

MP3packer 0.10 should keep the delays. Which version are you using?

Using MP3packer on a LAME 3.90.3 API encode won't give you the same savings as with 3.96.1 because API in 3.90.3 actually uses the bit reservoir. 3.96.1 doesn't, so any unused bits in a frame are wasted. This is what MP3packer was designed to clean up. There was a big, flame-riddled thread about this somewhere.

[ edit: I hadn't realized that 3.97 uses the bit reservoir again. I'm also getting ~0.1% improvement in API. I guess my "2-10%" statement was pretty short-lived! ]

(PS. The output file is 1/1000 smaller, or 0.1% smaller, but not 1/1000%  )
Title: MP3 repacker
Post by: [JAZ] on 2006-02-24 13:16:40
i used winmp3packer  feb/04, version 0.4.2226.41761  (extracted from file properties)
and mp3packer.pl feb/13 version 0.10  (I opened the file and has the whatsnew for 0.10)

I've searched all my hard drive to verify that there isn't another mp3packer.pl.

(thanks for pointing out the % typo :S )
Title: MP3 repacker
Post by: Omion on 2006-02-24 19:52:56
Hm. Weird. Maybe 3.90.3 writes a different type of LAME header than I'm used to and mp3packer doesn't parse it correctly.

Do you think you could e-mail me the first ~100K of the file? I PMed you with my e-mail address.
Title: MP3 repacker
Post by: Omion on 2006-02-25 20:23:52
Hm. Did you run mp3gain on the file?

Normally XING tags have a null side info, but this one didn't. Everything is null except the frame gain information. My program sees the non-null side info and assumes that the frame has actual audio data in it. The spec says that XING/LAME tags should have nothing in the side info, but I suppose I can work around it.

I'm currently working on the next version. It's a complete rewrite in OCaml, and it uses "1.5" passes, so it'll be faster and use less memory. And it won't require any runtimes or anything, so everybody without Perl can stop complaining.
Title: MP3 repacker
Post by: [JAZ] on 2006-02-26 00:15:34
Quote
Hm. Did you run mp3gain on the file?
[a href="index.php?act=findpost&pid=367253"][{POST_SNAPBACK}][/a]


I don't remember (I did it in 2003), but it's quite possible, since i wanted to do mixes..
Title: MP3 repacker
Post by: Omion on 2006-03-11 10:23:51
I just whipped together a simple beta-quality version of the next mp3packer. (version 0.9.99)

New features:
* Completely rewritten in OCaml
* Standalone Windows binary (no runtimes or perls needed anymore)
* Uses less memory than the old "-m" option
* Faster than the fastest setting for the old versions

Still needs work:
* Only file -> file works at the moment (no directory support)
* NOT extensively tested yet
* No binaries for any other operating systems. I'll release the source when I get everything organized
* I'm really tired right now and have no idea what kind of bugs I just introduced
* Usage screen does not appear if no files are given. Use "-help" to view.

Get it here (http://omion.dyndns.org/mp3packer/mp3packer-0.9.99.rar). I'm going to bed.
Title: MP3 repacker
Post by: krmathis on 2006-03-11 12:07:09
/me wait for the source code!
Title: MP3 repacker
Post by: psyllium on 2006-03-12 09:43:34
Quote
I just whipped together a simple beta-quality version of the next mp3packer. (version 0.9.99)

New features:
* Completely rewritten in OCaml
* Standalone Windows binary (no runtimes or perls needed anymore)
* Uses less memory than the old "-m" option
* Faster than the fastest setting for the old versions

Still needs work:
* Only file -> file works at the moment (no directory support)
* NOT extensively tested yet
* No binaries for any other operating systems. I'll release the source when I get everything organized
* I'm really tired right now and have no idea what kind of bugs I just introduced
* Usage screen does not appear if no files are given. Use "-help" to view.

Get it here (http://omion.dyndns.org/mp3packer/mp3packer-0.9.99.rar). I'm going to bed.
[a href="index.php?act=findpost&pid=370780"][{POST_SNAPBACK}][/a]


WOW talk about a speed improvement! Well done. I've found there's minimal change required for the GUI, so y'all can expect a new version of the WinMP3Packer soon enough. The only thing that is missing at the moment is the status messsages to give the % complete on individual files... not such a big deal now that it runs so fast.

If I am a bit slow in doing this though, send a reminder post on the WinMP3Packer thread - I have subscribed to it
Title: MP3 repacker
Post by: Omion on 2006-03-15 06:42:45
Quote
Well done. I've found there's minimal change required for the GUI, so y'all can expect a new version of the WinMP3Packer soon enough.

If I am a bit slow in doing this though, send a reminder post on the WinMP3Packer thread - I have subscribed to it
[a href="index.php?act=findpost&pid=370983"][{POST_SNAPBACK}][/a]
No hurry. I still haven't nailed down what I want the options to be like. OCaml doesn't have nearly as good a command-line argument parser as Perl does, so I might just make my own.

Quote
WOW talk about a speed improvement!
Yeah, it is a tad faster. The combination of doing both passes simultaneously and switching from Perl really speeds things up. I didn't really do any optimizations or anything.

Quote
The only thing that is missing at the moment is the status messsages to give the % complete on individual files... not such a big deal now that it runs so fast.
Oh yeah. I forgot about that. I added it to the "-i" info processing, but not the repacking. It'll be in the next release.

I'll try to get a "less-beta" version out in the next few days.
Title: MP3 repacker
Post by: Omion on 2006-03-16 04:34:38
All right, I think this is good enough. I just released version 1.00 of mp3packer, freshly rewritten in OCaml. It works a bit differently from the Perl version.
* Full-directory parsing is no longer available. This will be fixed in the near future.
* Ditto for the "-X" delete input file option.
* No runtimes or Perls or extra downloads required.
* The "-m" switch is no longer needed or supported. The new version reads the file once (like the old "-m" mode) but uses about the same amount of memory as the 2-pass normal mode.
* The arguments can no longer be tacked together. In the Perl version, "-st" meant "-s -t". Now "-st" will throw an error.
* New "-debug" switch for... debugging. Use "-debug all" to print out heaps o' data.

Also, the "-b" switch has been modified slightly. If an exact bitrate is given (like "-b 128") the program will change the smallest bitrate per frame to allow a more exact bitrate. For example "-b 128" will limit the first frame to an unpadded 128kbps frame, wheras the second frame will be limited to a padded 128kbps frame.

The result of this is that if all frames are the smallest possible, it follows the standard CBR dithering pattern.

If you give a number to "-b" which is one more than a valid bitrate, then the smallest bitrate would be a padded frame of that bitrate. All other bitrates round up to the next highest unpadded bitrate. For example:
Code: [Select]
130 -> Unpadded 160
129 -> Padded 128
128 -> Unpadded, padded, padded... 128 (depending on frame)
127 -> Unpadded 128
126 -> Unpadded 128
113 -> Padded 112
112 -> Unpadded, padded padded, unpadded... 112


One of the results of this is that the highest bitrate possible is actually obtained with "-b 321" which results in a bitrate of 320.03 kbps.

ALSO NOTE:
The Perl versions were public domian, the new versions will be GPL. This means it can still be distributed with closed-source applications like psyllium's winmp3packer, but it should point out the copyright holder (me!) and contain a copy of the GPL.
Title: MP3 repacker
Post by: krmathis on 2006-03-17 20:10:47
Omion. I try to compile the MP3 Repacker source on Mac OS X, but it dont play nicely.
I ocaml-3.09.1 installed and working. But the process fail when I run "make".

Quote
make
ocamlopt -c mp3types.ml
ocamlopt -c pack.ml
ocamlopt -c mp3types.cmx pack.cmx mp3read.ml
File "mp3read.ml", line 426, characters 16-26:
Unbound value Crc.create
make: *** [mp3read.cmx] Error 2

Do you have any hints?
I have never heard of 'ocaml' before, so this is all new to me.
Title: MP3 repacker
Post by: Omion on 2006-03-17 20:22:38
Oops. I think my makefile isn't in the right order. Run "make mp3packer" to do things correctly. makefiles are pretty new to me

[edit: deleted quote]
Title: MP3 repacker
Post by: krmathis on 2006-03-17 20:45:07
Success!
Now on to testing this...
Title: MP3 repacker
Post by: psyllium on 2006-04-09 06:40:39
Hey does anyone have a copy of the rar file (for either the executable and/or the source) that they could send me? I'm having trouble downloading it.

Thanks
Title: MP3 repacker
Post by: neomoe on 2006-04-09 10:21:23
removed my URL. wrong package. sorry.
Title: MP3 repacker
Post by: Omion on 2006-04-09 18:52:04
Hey does anyone have a copy of the rar file (for either the executable and/or the source) that they could send me? I'm having trouble downloading it.

Thanks

I really shouldn't set my hosting computer to go to standby.  My site should be working now.

I'm going to purchase a new computer soon to host everything off of. That should help the availability, since I crash my main computer far too often.
Title: MP3 repacker
Post by: Omion on 2006-04-14 04:56:46
1.01 is out.

Squashed a bug when the bit reservoir goes off the beginning of the file (thanks, psyllium!)

The problem was that if, for some reason, the bit reservoir wanted more bytes than were actually in the buffer at any given time, the program would die. This only happens with corrupt mp3 files, but will happen quite a bit if the file was split with a naïve splitter that doesn't redistribute the bit reservoir data.

I have no idea why it was happening on psyllium's files, but it'll just put up a warning that the first frame(s) may be garbage, instead of croaking.
Title: MP3 repacker
Post by: psyllium on 2006-04-15 06:00:25
1.01 is out.

Squashed a bug when the bit reservoir goes off the beginning of the file (thanks, psyllium!)

The problem was that if, for some reason, the bit reservoir wanted more bytes than were actually in the buffer at any given time, the program would die. This only happens with corrupt mp3 files, but will happen quite a bit if the file was split with a naïve splitter that doesn't redistribute the bit reservoir data.

I have no idea why it was happening on psyllium's files, but it'll just put up a warning that the first frame(s) may be garbage, instead of croaking.


Yeah the files were split with mp3splt.
Title: MP3 repacker
Post by: Omion on 2006-04-15 09:23:24
Oops. It looks like I didn't quite squash that bug.

I 'fixed' it by changing the internal offset and length of the frame data to not go off the front of the file. However, I just noticed that I don't actually output the new frame length. This means that if you re-run mp3packer on the output file, it will crash with the same error message. I turned a buffer underrun into a delayed buffer overrun. 

Anyway, fixing it may take a bit of time, since it looks like Visual Studio got COMPLETELY screwed up. I'll fix it as soon as I can (it shouldn't be too hard)
Title: MP3 repacker
Post by: Omion on 2006-04-20 19:55:49
Oops. It looks like I didn't quite squash that bug.

1.02 out. Actually fixed the underrun this time. Also fixed another problem when a weird XING tag is present.
Title: MP3 repacker
Post by: Architectonical on 2006-05-14 12:17:11
I'd like to try this, so if you could rehost it, that would be great.
Title: MP3 repacker
Post by: Antonski on 2006-05-14 19:41:20
@Architectonical: Check your PM
Title: MP3 repacker
Post by: Gnerma on 2006-05-15 02:29:12
Could I get a copy too? I could host it for the time being if somebody sends me the file.

Thanks

EDIT - nevermind, the link is live again. Thanks Omion.

EDIT2 - Well it tried it out. It's certainly nifty being that I'm all for efficienty. I'd do a complete run on my whole collection if that was possible
Title: MP3 repacker
Post by: Omion on 2006-05-17 19:46:27
Oops. I just saw the recent responses. Sorry for the hosting issues. My server is hooked up wirelessly to the router. It's about 8 feet away, but sometimes it just loses the signal altogether. I'll try to get a mirror on my main computer in case it dies again.

@all:
The links shouldn't be broken for more than a few hours at a time, so just keep trying. If that doesn't help, send me a PM and I'll e-mail it to you.
Title: MP3 repacker
Post by: Omion on 2006-05-28 09:32:38
Released 1.03.

mp3packer will now check to see if the frame is silent. If it is, all the frame's data will be cleared (there's no point in having any data if it's going to be thrown out anyway)

This mainly affects FhG encodes, which will pad frames in such a way that mp3packer can't pack them. Actually getting the data would require a "rehuff" type program, which I'm not going to write. So I made a special case for silent frames. It's not going to help in the vast majority of cases, but the entire program shouldn't need to exist in the first place 


PS. Hosting issues should be more or less gone. I now host the files off a RAM drive instead of a CompactFlash card. Much faster
Title: MP3 repacker
Post by: Gabriel on 2006-05-28 09:48:04
PS. Hosting issues should be more or less gone. I now host the files off a RAM drive instead of a CompactFlash card. Much faster

What kind of host is it? A diskless one?
Title: MP3 repacker
Post by: Omion on 2006-05-28 10:10:06
What kind of host is it? A diskless one?

Yup. I built my always-on computer to be as quiet as possible. That means passive CPU cooling and no hard drives. The power supply fan is the only moving part in it. But fitting Windows XP on a 1GB CompactFlash card was not easy... 

Of course, I didn't realize the amazing slowness of CompactFlash (although I didn't buy the fastest one). The result is that something would time out while files were being read, making for lots of incomplete transfers.

I just installed a trial to a RAM drive program, which I now have everything hosted off of. Of course, the demo will expire in 2 weeks, so I'll have to shell out $50 to get the full version.  But it's mighty fast!
Title: MP3 repacker
Post by: rutra80 on 2006-05-28 21:34:23
Omion, are you hosting your files on your machine because you want to, or because you have no choice?
Title: MP3 repacker
Post by: Firon on 2006-05-28 21:47:53
I can mirror the files on my server for you, if you want.
Title: MP3 repacker
Post by: psyllium on 2006-05-29 00:17:43

What kind of host is it? A diskless one?

Yup. I built my always-on computer to be as quiet as possible. That means passive CPU cooling and no hard drives. The power supply fan is the only moving part in it. But fitting Windows XP on a 1GB CompactFlash card was not easy... 

Of course, I didn't realize the amazing slowness of CompactFlash (although I didn't buy the fastest one). The result is that something would time out while files were being read, making for lots of incomplete transfers.

I just installed a trial to a RAM drive program, which I now have everything hosted off of. Of course, the demo will expire in 2 weeks, so I'll have to shell out $50 to get the full version.  But it's mighty fast!


If you use Linux, /dev/shm comes as a mounted ram disk automagically
Title: MP3 repacker
Post by: Firon on 2006-05-29 01:12:06
I assume he's using Windows, since RAMDisk XP is about $50
Title: MP3 repacker
Post by: kwanbis on 2006-05-29 04:23:01
I just installed a trial to a RAM drive program, which I now have everything hosted off of. Of course, the demo will expire in 2 weeks, so I'll have to shell out $50 to get the full version.  But it's mighty fast!

did you try http://support.microsoft.com/kb/q257405/ (http://support.microsoft.com/kb/q257405/)

or

http://users.compaqnet.be/cn021945/RAMDisk/ramdiskfree.htm (http://users.compaqnet.be/cn021945/RAMDisk/ramdiskfree.htm)
Title: MP3 repacker
Post by: Omion on 2006-05-29 06:31:17
Omion, are you hosting your files on your machine because you want to, or because you have no choice?

Well, I technically have space on my university server, but I don't know how long it will be there. It's been a few years since I've been in school. I guess I mainly host them myself because I can. Of course, anybody can put up mirrors if they like.

BTW, are people still having problems with downloading? My apache log file is showing there haven't been any restarted transfers today. (it used to take a few tries to get the whole thing)


For those who want the gory details of my setup:
Windows XP (I seriously considered Linux, but I'm still more comfortable with Windows. I might end up installing Ubuntu when the RamDisk trial expires)
Super-slow 1GB CompactFlash card in one of these (http://www.newegg.com/Product/Product.asp?Item=N82E16822998002)
Trial to SuperSpeed RamDisk Plus with two HD-backed drives (one for Apache which saves on shutdown, and the other for the data which is thrown out on shutdown)
The whole setup is connected wirelessly  to my main computer, where I control it with Remote Desktop.

It's dead silent, and only has one cable coming out of it (power).


@kwanbis:
There are 2 big problems with most ram drives:
1) Most are limited to 32 or 64MB. I have at least 100MB of stuff on my site
2) Most won't save the image on shutdown or load it on startup.
The SuperSpeed program was the only one I found which could do exactly what I wanted (other than Linux, of course  )

I played around with having Apache do some very aggressive caching, but that resulted in some bizarre server responses for some reason.
Title: MP3 repacker
Post by: Firon on 2006-05-29 06:44:46
Here's a mirror. http://download.utorrent.com/mp3packer-1.03-123.rar (http://download.utorrent.com/mp3packer-1.03-123.rar)
http://download.utorrent.com/mp3packer-1.03-123_src.rar (http://download.utorrent.com/mp3packer-1.03-123_src.rar)
Title: MP3 repacker
Post by: psyllium on 2006-06-10 14:06:04
Version 1.0.3 of WinMP3Packer has been released here (http://winmp3packer.webhop.net). Includes version 1.03 of mp3packer.exe
Title: MP3 repacker
Post by: bukem on 2006-06-24 18:26:27
i've been playing with mp3packer 1.03 tool for a week without any problems till now. i've got one mp3 in my collection (CBR 192kbps) and every time i try to pack it with mp3packer i get following error in the middle of the process.
Quote
Fatal error: exception Invalid_argument("Buffer.sub")

I've checked that mp3 with mp3trim for any errors and found none. please find the "mp3packer -i" output bellow.
Quote
INFO:
MPEG1 layer 3
20401 frames
44100 Hz
38.281250 frames per second
532.924082 seconds
12772182 bytes in file (191.729853 kbps)
12771026 bytes in MP3 frames (191.712500 kbps) = current bitrate
96286830 bits of payload data (180.676448 kbps)
12036754 bytes of payload data (180.689962 kbps)
7202 bits wasted from partially-full bytes (0.013514 kbps)
12771190 bytes of MP3 data (191.714962 kbps) = minimum bitrate possible
-164 bytes of padding (-0.002462 kbps)
1156 bytes outside MP3 frames (0.017353 kbps)
Bitrate distribution:
  192: 20401,0
Largest frame uses 6864 bits = 858 bytes = 262.762500 kbps
Smallest bitrate for CBR is 192


isn't a negative value for padding a strange thing?

ps. i can upload somewhere the mp3 file i'm talking about for debugging purpose if needed
Title: MP3 repacker
Post by: Tonio Roffo on 2006-06-24 19:54:37
WinMP3packer fails to install on XP x64 - keeps asking for .NET framework 1.1.x, I have x64 .NET framework installed.
Title: MP3 repacker
Post by: Omion on 2006-06-24 19:56:16
i've been playing with mp3packer 1.03 tool for a week without any problems till now. i've got one mp3 in my collection (CBR 192kbps) and every time i try to pack it with mp3packer i get following error in the middle of the process.
Quote
Fatal error: exception Invalid_argument("Buffer.sub")

...
isn't a negative value for padding a strange thing?

ps. i can upload somewhere the mp3 file i'm talking about for debugging purpose if needed

A negative value for padding is indeed a strange thing. And that's probably what went wrong. For some reason a frame references bytes that have already been used in a previous frame. I thought I turned that into a warning, but I guess not.

If the file's smaller than 10MB, you can e-mail it to me. I'll PM you my address.
Title: MP3 repacker
Post by: bukem on 2006-06-24 21:40:40
Unfortunately the file is 12MB, but I've managed to upload it to the RapidShare. I hope that it will help you debug the problem. BTW, I should mention it before - thank you for mp3packer, it's great tool!

Ps. and here comes the link -> suspicious mp3 file (http://rapidshare.de/files/24012871/09._atjazz_-_touch_the_sun__king_britt_s_scuba_journey_.mp3.html)
Title: MP3 repacker
Post by: Omion on 2006-06-25 07:48:35
Thanks for the file. It looks like the problem is a buffer overrun, right where I added the code to protect against a buffer underrun in 1.02. The odd thing is that the file looks perfectly OK, but it's requesting 9 bytes from the frame following the problem frame. Then the next frame wants 469 bytes from the bit reservoir... the file just seems to be screwed up right there, and my program is panicking.

I just checked, and Foobar will skip to the next song at 6:05, which is right where the problem frame occurs. [edit: I just checked again, and Foobar is no longer skipping to the next song there... odd]
No other mp3 checker programs would have caught it, because I don't think they check the bit reservoir for invalid stuff.

So I'll do a check for buffer overruns, and put up a warning and pad with garbage if that happens (just like I do with underruns)


@psyllium:
Your /dev/shm comment pushed me over the edge...
I got my diskless server running Ubuntu Linux, and it's quite awesome. I make it automatically mount a ramdisk on startup, fill it up with my web site, and synchronize new files every few hours. All without 3rd party tools. MAN, Linux is powerful. 
The only thing I miss from Windows is filesystem-based compression like NTFS has. That would have saved me a lot of headaches. Well, it's only a matter of time before some Linux FS supports it.
Title: MP3 repacker
Post by: bukem on 2006-06-25 11:32:14
Thanks Omion for your help. I'm looking forward for new version of mp3packer.
Title: MP3 repacker
Post by: kerminen on 2006-06-25 13:30:11
@Omion:

http://www.cenatek.com/product_ramdisk.cfm (http://www.cenatek.com/product_ramdisk.cfm)

ramdisks up to 3GB, there is a comprehensive Users manual to download from that web page...
Title: MP3 repacker
Post by: Firon on 2006-06-25 19:36:41
Costs like $50 for a license, unfortunately.
Title: MP3 repacker
Post by: Omion on 2006-06-26 07:56:44
Allrighty, 1.04's out.

Fixed bukem's issue, so it will now put up a warning that something is wrong instead of crashing. Note that there will still be a minor glitch where the error occurred.

Also tweaked the silent-frame detection algorithm, and made it optional. If you have a song which has a lot of silence in it, but mp3packer isn't doing anything to it, use the -z option. The reason I made it an option is that I don't know if my criteria for silent frames will actually include some non-silent frames.

There was another obscure LAME/XING tag related bug which is also squashed.


@kerminen:
Firon pointed out why I didn't consider that. I actually had a pretty good ramdisk for Windows, but it was also a trial to a $50 program. In the end, Linux is free. 

I'm still having some issues with Linux (well, I think it's my CF card) and wireless support is no good, but I think I'll stick with Linux, at least on that computer. It just feels better.
Title: MP3 repacker
Post by: bukem on 2006-07-14 17:09:22
@Omion:

Sorry for bothering you again, but I've found another problematic mp3 files:

1. Fatal error: exception Mp3types.Too_many_bytes case:

Again, the suspicious file (http://rapidshare.de/files/25837484/02._the_method_-_i_ve_got_a_cat.mp3.html) seems to have problems with the bit reservoir, but nevertheless to implemented by you buffer checks it's crashing mp3packer v1.04-126. Here you have output:

Code: [Select]
D:\tmp>mp3packer -i "02. the method - i've got a cat.mp3"
*** '02. the method - i've got a cat.mp3'
INFO:
MPEG1 layer 3
7489 frames
44100 Hz
38.281250 frames per second
195.631020 seconds
6260727 bytes in file (256.021851 kbps)
6260192 bytes in MP3 frames (255.999973 kbps) = current bitrate
47901297 bits of payload data (244.855325 kbps)
5990964 bytes of payload data (244.990349 kbps)
26415 bits wasted from partially-full bytes (0.135025 kbps)
6260568 bytes of MP3 data (256.015349 kbps) = minimum bitrate possible
-376 bytes of padding (-0.015376 kbps)
535 bytes outside MP3 frames (0.021878 kbps)
Bitrate distribution:
  256: 612,6877
Largest frame uses 8704 bits = 1088 bytes = 333.200000 kbps
Smallest bitrate for CBR is 320

D:\tmp>mp3packer "02. the method - i've got a cat.mp3"
*** '02. the method - i've got a cat.mp3' -> '02. the method - i've got a cat-vbr.mp3'
0% done on frame 0
Buffer underflow; added 451 zeros to the beginning of frame 0
Fatal error: exception Mp3types.Too_many_bytes


2. Fatal error: exception End_of_file case:

That file (http://rapidshare.de/files/25838008/01._stylin__-_drifting_sun.mp3.html) this time crash the mp3packer completely.

Code: [Select]
D:\tmp>mp3packer -i "01. stylin' - drifting sun.mp3"
*** '01. stylin' - drifting sun.mp3'
Fatal error: exception End_of_file

D:\tmp>mp3packer "01. stylin' - drifting sun.mp3"
*** '01. stylin' - drifting sun.mp3' -> '01. stylin' - drifting sun-vbr.mp3'
Fatal error: exception End_of_file


FYI -> mp3trim doesn't report any problems with these files.
Title: MP3 repacker
Post by: kevinsham on 2006-07-15 13:07:17
Quote
A feature request:
Rename the original file and use the input file name as output.
[a href="index.php?act=findpost&pid=363922"][{POST_SNAPBACK}][/a]
Ah yes. 
As in: shove '-orig' on the end of the original input file, and thus the resulting output file can have the original's original name (follow me!?).


Is this feature planned to be included in the future?
Thank you very much.
Title: MP3 repacker
Post by: Omion on 2006-07-15 16:00:44
@kevinsham (and others):
I should be able to add original-file renaming to the next version.

Code: [Select]
D:\tmp>mp3packer -i "02. the method - i've got a cat.mp3"
*** '02. the method - i've got a cat.mp3'
-376 bytes of padding (-0.015376 kbps)

D:\tmp>mp3packer "02. the method - i've got a cat.mp3"
*** '02. the method - i've got a cat.mp3' -> '02. the method - i've got a cat-vbr.mp3'
0% done on frame 0
Buffer underflow; added 451 zeros to the beginning of frame 0
Fatal error: exception Mp3types.Too_many_bytes


Code: [Select]
D:\tmp>mp3packer -i "01. stylin' - drifting sun.mp3"
*** '01. stylin' - drifting sun.mp3'
Fatal error: exception End_of_file

D:\tmp>mp3packer "01. stylin' - drifting sun.mp3"
*** '01. stylin' - drifting sun.mp3' -> '01. stylin' - drifting sun-vbr.mp3'
Fatal error: exception End_of_file

I think I know the problems with both files. The first one appears to have been cut improperly (hence the buffer underflow warning and negative padding). The problem is that whereas the original file could put those bytes in the previous (non-existant) frame, mp3packer has no such luxury and panics because there are too many bytes.

The second problem is due to the XING frame not having CRC data, but the rest of the frames do. My program reads the XING tag, assumes that all valid frames have no CRC data, and throws out the rest of the frames.

I should be able to fix both problems tomorrow.
Title: MP3 repacker
Post by: Omion on 2006-07-17 07:47:18
All right. Got 1.05 out.

I added the -u switch to do original-file renaming as many have suggested. For example:
Code: [Select]
mp3packer -u file.mp3 file-orig.mp3
will rename file.mp3 to file-orig.mp3, then save the packed version as file.mp3.

Note that if you use the -u option and leave off the output file, the original file will have "-vbr" appended to it, instead of the new file. This is the default from before, but it doesn't make much sense with -u. So always either specify the output file or use something like "-a -orig" to override the appending.

I also sort of fixed the problems bukem was having. The second file now works flawlessly, but the first file is still a bit odd. There are at least 3 things wrong with it:Everything else should be OK though.
Title: MP3 repacker
Post by: bukem on 2006-07-17 13:03:43
@Omion:

Thanks again. I'm going to check new version of mp3packer ASAP and let you know the results.

Edit: [@Omion] I'm in the middle of the conversion process of ~30 GB mp3 test set. That's step one. Next step is to bit compare source tracks with converted tracks to find any inconsistency - if any I'll let you know.
Title: MP3 repacker
Post by: Omion on 2006-07-20 21:14:29
[@Omion] I'm in the middle of the conversion process of ~30 GB mp3 test set. That's step one. Next step is to bit compare source tracks with converted tracks to find any inconsistency - if any I'll let you know.

Very cool. That would really help improve/confirm the stability of mp3packer. Unfortunately, I don't know of any way to automate the "Bit-compare tracks" command from Foobar, so it may take a while.

Also note that if a file reports an error in mp3packer, the conversion will probably not be lossless. However, if there was an error, then the file was "wrong" to begin with, so being bit-exact won't matter. (If you have too much time on your hands, though, you can check to make sure that the lossy parts are only concentrated around the error)

BTW, I found out that the non-exactness of the "I've got a cat" file was due to Foobar. Testing it with 0.9 reports  no differences. I had previously used 0.8.3, which apparently had an extremely minor roundoff issue. Which is a relief, because I was pulling my hair out looking at the hex output of mp3packer, trying to see what went wrong. It's a good thing it's not my fault  That means that, if you can, use 0.9 to do the comparison.
Title: MP3 repacker
Post by: bukem on 2006-07-21 00:04:15
@Omion

Quote
BTW, I found out that the non-exactness of the "I've got a cat" file was due to Foobar. Testing it with 0.9 reports no differences. I had previously used 0.8.3, which apparently had an extremely minor roundoff issue.

Really good news . I was a bit afraid that mp3packer may lose some bits.

Quote
Unfortunately, I don't know of any way to automate the "Bit-compare tracks" command from Foobar, so it may take a while.

That's not a problem. With f2k you can bit-compare several tracks at once. Just add folder with source mp3's to the playlist and then add folder with converted mp3's to the same playlist, select all tracks, rightclick and choose bit-compare and voila!

BTW. It seems that I've found a small glitch in WinMp3Packer GUI - I have to write simple batch file to convert the test set again. Edit: My fault
Title: MP3 repacker
Post by: Omion on 2006-07-21 00:10:09
That's not a problem. With f2k you can bit-compare several tracks at once. Just add folder with source mp3's to the playlist and then add folder with converted mp3's to the same playlist, select all tracks, rightclick and choose bit-compare and voila!

Whoa.  That is AWESOME. I just keep liking Foobar more and more.
Title: MP3 repacker
Post by: bukem on 2006-07-21 00:16:42
@Omion
Yeah, F2K is the tool you can fall in love with . BTW, I just had to start the conversion process again because of my fault (too drunk?) so I'll update you about results tomorrow.
Title: MP3 repacker
Post by: Firon on 2006-07-21 00:59:32
Yeah, it compares the first half of the tracks with the counterpart in the second half of the list. Works the same for the masstagger's copy tags function.
Title: MP3 repacker
Post by: bukem on 2006-07-21 01:49:08
@Omion

I've found first broken mp3 (http://rapidshare.de/files/26468157/01._fatboy_slim_-_right_here__right_now.mp3.html) file in my test set. It's negative padding case again. In fact all tracks from that particular album have the same issue.

Here's output from mp3packer -i:
Code: [Select]
*** '01. fatboy slim - right here, right now.mp3'
INFO:
MPEG1 layer 3
14851 frames
44100 Hz
38.281250 frames per second
387.944490 seconds
9091943 bytes in file (187.489566 kbps)
9091413 bytes in MP3 frames (187.478637 kbps) = current bitrate
106667278 bits of payload data (274.955002 kbps)
13339229 bytes of payload data (275.075004 kbps)
46554 bits wasted from partially-full bytes (0.120002 kbps)
13873865 bytes of MP3 data (286.100004 kbps) = minimum bitrate possible
-4782452 bytes of padding (-98.621367 kbps)
530 bytes outside MP3 frames (0.010929 kbps)
Bitrate distribution:
   32: 9,0
   48: 1,0
  128: 898,0
  160: 5798,0
  192: 5435,0
  224: 1253,0
  256: 718,0
  320: 739,0
Largest frame uses 15488 bits = 1936 bytes = 592.900000 kbps
Fatal error: exception Mp3types.Too_many_bytes


Edit:
I've found solution in that case -> Fix MP3 Header from F2K did the trick! After that mp3packer has no problems with these tracks.

Code: [Select]
*** '01. fatboy slim - right here, right now.mp3.mp3'
INFO:
MPEG1 layer 3
14850 frames
44100 Hz
38.281250 frames per second
387.918367 seconds
9091995 bytes in file (187.503264 kbps)
9091257 bytes in MP3 frames (187.488044 kbps) = current bitrate
68159667 bits of payload data (175.706212 kbps)
8526466 bytes of payload data (175.840418 kbps)
52061 bits wasted from partially-full bytes (0.134206 kbps)
9061066 bytes of MP3 data (186.865418 kbps) = minimum bitrate possible
30191 bytes of padding (0.622626 kbps)
738 bytes outside MP3 frames (0.015220 kbps)
Bitrate distribution:
   32: 9,0
  128: 898,0
  160: 5798,0
  192: 5435,0
  224: 1253,0
  256: 718,0
  320: 739,0
Largest frame uses 8918 bits = 1115 bytes = 341.392187 kbps
Smallest bitrate for CBR is 320


The strange thing, though, that mp3trim doesn't found any problems with these tracks?
Title: MP3 repacker
Post by: Omion on 2006-07-21 02:23:42
Wow. There's 4MB of MP3 data which just isn't in the file! I'll find out what's going on. Just keep sending me the broken ones
Title: MP3 repacker
Post by: bukem on 2006-07-21 02:33:19
In fact I just found and fixed another album which had the same symptoms like that one before. Fix MP3 Header helped again
Title: MP3 repacker
Post by: Omion on 2006-07-21 02:57:02
Bleh. I found the problem. The XING frame is not parsed as an XING frame (it may be invalid... I'll have to check) and so something happens which causes mp3packer to think that the CRC in each frame is actually the bit-reservoir offset. Hilarity ensues.

I'll get this fixed soon.

EDIT: I fixed the errors all over the place, but now it throws out all the frames. Keep hacking...
Title: MP3 repacker
Post by: Omion on 2006-07-21 04:51:55
I think I fixed the problem. Get 1.06.

The problem, if you really want to know, is that the XING tag's frame does not have a CRC on it, and it also does not specify an encoder. mp3packer sees that it doesn't have an encoder, assumes that it's not an XING frame, then assumes that all other valid frames don't have CRCs either. HOWEVER, I never actually check if the other frames have CRCs, so the CRC is used for the bit reservoir offset. This creates errors all over the place, until there is eventually too much data to even fit into a 320kbps frame. The program then croaks.

Aren't you glad you asked? (oh wait. You didn't ask...)
Title: MP3 repacker
Post by: bukem on 2006-07-21 14:31:38
Omion, how about another nasty mp3 track (http://rapidshare.de/files/26517721/14._fila_brazillia_-_in_the_kingdom_of_sound.mp3.html) ?  . It fails in mp3packer with too_many_bytes error, but when treat with f2k's fix mp3 header magic happens and mp3packer has no problems with processing that file anymore.

Edit: Do anybody know what exactly f2k's fix mp3 header fuction do? Forget it - I've found answer 
Title: MP3 repacker
Post by: Omion on 2006-07-21 15:55:56
Bleh. It's that LAME tag being inconsistant again. The LAME tag header says that it's not original, but the rest of the frames are original. I fixed it, but I don't have time right now to release it, but here's (http://omion.dyndns.org/mp3packer/mp3packer-pre1.07.exe) an EXE that should be fixed.
Title: MP3 repacker
Post by: bukem on 2006-07-22 13:20:54
Great! I've just finished mp3packing 37 531 877 KB of mp3 music (4862 tracks) and I saved 166 657 KB which is about 0.44 %. Now I've started bit-comparing source and mp3packed tracks to find any inconsistency (hope not ).

Edit 1:
I've found first inconsistent track (http://rapidshare.de/files/26640300/01._scalar_-_solar.mp3.html)  ).

Code: [Select]
Comparing:
"R:\music\..good looking records\.other\studio x\01. scalar - solar.mp3"
"D:\documents\music\.streams\music\..good looking records\.other\studio x\01. scalar - solar.mp3"
Comparing failed (length mismatch).


Edit 2:
Something is wrong here. Till now in 722 mp3 tracks, f2k bit-compare found 65 files with differences, 125 files failed to compare because of Comparing failed (length mismatch) 

And here an example (http://rapidshare.de/files/26653100/looking_good_-__lgr019__01._moonchild_-_seatown.mp3.html)  of mp3 with differences:
Code: [Select]
Comparing:
"R:\music\..good looking records\.other\.singles\looking good - (lgr019) 01. moonchild - seatown.mp3"
"D:\documents\music\.streams\music\..good looking records\.other\.singles\looking good - (lgr019) 01. moonchild - seatown.mp3"
differences found: 3255 sample(s), starting at 25.5749887 second(s), peak: 0.1141328 at 25.5886621 second(s), 2ch


Edit 3:
Huston, we have a problem -> another 614 files processed and here are results:
83 files - Comparing failed (length mismatch)
109 files - Differences found
Title: MP3 repacker
Post by: Omion on 2006-07-23 04:09:26
Huston, we have a problem -> another 614 files processed and here are results:
83 files - Comparing failed (length mismatch)
109 files - Differences found
Run a few of the files that had errors through mp3packer again and look for any errors that may have occurred. There may have been over/underruns in the files which mp3packer threw out. Your example in "Edit 2" looks like there may have been a bad frame or two.

Also, I don't think I've ever run across a "Comparing failed (length mismatch)" error... What version of Foobar are you using? Could you upload an mp3 that does it? [ edit: Oops. You did upload one. Testing... ]


Actually, I just realized that mp3packer does not give a warning for sync errors, which may make it difficult to see if the error was in the original or in the conversion.

One more thing: you didn't use the -z switch, did you?
Title: MP3 repacker
Post by: Omion on 2006-07-23 05:37:37
Grr.... It looks like Foobar has a much more lax idea of what a LAME header is supposed to look like. The problem with the first file (Scalar - Solar) is not really a problem in either mp3packer or Foobar, but how they interpret the LAME data.

All LAME headers have a CRC at the end, which identifies it as valid. mp3packer checks this before it uses the LAME tag data, but Foobar (apparently) does not. Therefore, Foobar will use the offsets stored in the LAME header whereas mp3packer will not.

The end result of this is that Foobar will start playing the output file 576 samples before the input file. I checked, and this was the only error on Scalar - Solar.


This is a bit of a problem, as I have no intention of making mp3packer read invalid LAME headers, whereas Foobar sees nothing wrong with it. I may just have to give in and make an exception for the offsets...

Probably the best fix right now is to run Foobar's "Fix MP3 Header" on the problem files. It should fix a large majority of the problems. (It is a bit time-consuming, though, as you have to "fix" each file separately)


I'm still checking on the Seatown song... that may be a genuine bug.
[ EDIT: I found out that the original Seatown has a little glitch right where the difference is occurring (25 seconds). If the side info is broken right there, mp3packer and Foobar may have different ways of dealing with it. Conclusion: not a bug in mp3packer (but a bug in the MP3) ]
Title: MP3 repacker
Post by: Omion on 2006-07-23 07:35:36
OK. 1.07 is out. There is now no reliance on the LAME/XING frame header for MP3 information. Also, I "fixed" the issue of the offsets.

I say "fix" because all I did was allow certian types of invalid LAME tags to slip through the CRC detection. If the LAME tag has nothing but offset info, it is treated as a valid LAME tag. If anything else is present and the CRC is incorrect, it is thrown out and only the XING part is used.

It should fix at least bukem's 83 "length mismatch" problems. I don't know about the others.
Title: MP3 repacker
Post by: bukem on 2006-07-23 16:08:17
@Omion:

1. I'll start uploading problematic mp3's at your server ASAP.
2. I used f2k 0.9.3 beta 2 for bit-comparing.
3. I didn't use -z switch for mp3packer.

I'll stay in touch - thanks for your time and work you put into mp3packer.

Edit:
I've found one but maybe very important thing (I don't know why I missed it...) - in most cases when differences where found during bit-comparing they started at 0.0000000 seconds and took around 3500 samples. Interesting, don't you think so?
Title: MP3 repacker
Post by: Omion on 2006-07-23 18:01:20
Edit:
I've found one but maybe very important thing (I don't know why I missed it...) - in most cases when differences where found during bit-comparing they started at 0.0000000 seconds and took around 3500 samples. Interesting, don't you think so?

Hmm. That is interesting. It sounds like it may be due to the MP3 being split improperly, and mp3packer having to make up for that. I'll see what I can come up with.
Title: MP3 repacker
Post by: KAMiKAZOW on 2006-07-23 20:27:45
FYI I compiled an Mac OS X version of mp3packer. It can be downloaded from http://osx.iusethis.com/app/mp3packer (http://osx.iusethis.com/app/mp3packer)
Title: MP3 repacker
Post by: Omion on 2006-07-27 22:39:54
1.08 is out.

I added the -w switch, which will throw out an entire frame even if a buffer error only affects one granule of the frame. The default mode is to only throw out the granule which is bad.
The new switch will change nothing for well-formed mp3 files, but it will match Foobar's broken frame handling for easier verification.

@bukem:
The version that I sent you is the same as this, but has the -w switch hardcoded. Don't upgrade to 1.08 unless you can coax WinMp3Packer to use the -w switch. It will help with the error reports. Thanks! 

@KAMiKAZOW:
Thanks for the OSX build! I'm sure it will help Mac users out there. Just one question: did you have any problem compiling it?
Title: MP3 repacker
Post by: Omion on 2006-08-07 06:13:47
All righty. 1.09 is out.

mp3packer will now inform the user if there were any buffer or sync errors. Since the output has changed, WinMP3Packer may not interpret the results correctly (I haven't checked)

If buffer or sync errors occur, the output should look like this:
Code: [Select]
*** 'a.mp3' -> 'b.mp3'
WARNING: sync error; expected frame 4090 at 3018491
WARNING: buffer overflow; frame 4091 will be truncated
WARNING: sync error; expected frame 6726 at 5024182
100% done with 21686 frames

WARNING: There was 1 buffer error and 2 sync errors


The big news with this release is that I'm now quite certain that mp3packer is bit-identical for files with no errors. Thanks to bukem, mp3packer has been thouroughly tested with all sorts of input.

Synthesis of bukem's and my results on 4830 files tested with Foobar's Bit Compare Tracks: (bukem, correct me if I'm wrong )
4534 files returned no errors
This is the way it should be. 
91 files returned 1 to 3 samples different with peak equal to 0.000000.
This can only be explained by a decoder rounding issue. Having thouroughly looked into the issue, I came to the conclusion that mp3packer could not have done anything to cause this. The different samples tended to be on the order of -140dB, or completely silent even with 24-bit output. All other decoders I tried were 16-bit, and decoded to identical WAV files.
199 files failed to compare due to a "length mismatch" error.
Generally this was due to the encoder not giving the proper number of frames in the LAME header. Foobar saw the different number of frames and concluded that they were different without actually checking the data.
Occasionally the LAME header's CRC was computed incorrectly. Foobar seems to treat it as a LAME header anyway, but mp3packer will throw it out (it is invalid, after all...)
In both cases, using Foobar's Fix MP3 Header before packing resulted in files with identical audio.
6 files actually returned different samples.
I checked every one of the files, and there were no errors due to mp3packer.
* 3 files only came back different in Foobar. No other MP3 decoder that I used showed any differences. They all had invalid big_values on the problem frames, which may have had something to do with it.
* 2 files have broken frames which are handled differently in Foobar and mp3packer.
* 1 file had a bizarre problem where two frames pointed to the same data. Foobar and mp3packer handled that case differently.

It must be noted that all the files which failed comparison were invalid (other than the 91 files which resulted in decoder rounding errors).
Also, the differences were local to the region of the error. Sometimes the offset was incorrect, but all the samples were the same. Sometimes a frame was invalid, but all the samples to either side were identical.
Title: MP3 repacker
Post by: bukem on 2006-08-07 18:10:47
All you've posted is correct - thank you very much Omion. And thank you for detailed error report support in mp3packer.
Title: MP3 repacker
Post by: KAMiKAZOW on 2006-08-11 09:29:13
Just one question: did you have any problem compiling it?
None at all.
Title: MP3 repacker
Post by: maadjordan on 2006-08-20 16:57:53
i have tested the both the command line and GUI compile on a CBR of 160 bitrates with less than 1KB reduction of 10~18MB files . what could be the wrong

you can use http://media.libsyn.com/media/japanesepod1...906_jpod101.mp3 (http://media.libsyn.com/media/japanesepod101/223_N27_081906_jpod101.mp3)
Title: MP3 repacker
Post by: Firon on 2006-08-20 18:52:43
It'll only really work on high (much higher than 160) bitrate CBR files. Or CBR files with a lot of silence.
Title: MP3 repacker
Post by: Omion on 2006-08-20 19:07:46
A lot of files don't compress very well, especially below ~250kbps. mp3packer depends on wasted bits, but there tend not to be any at 160kbps.

So nothing's wrong, but there's not much that can be done about some files.
Title: MP3 repacker
Post by: Rain on 2006-09-23 13:24:32
Thanks Omion for making such a useful program! Quite impressive!
Title: MP3 repacker
Post by: Omion on 2006-09-29 04:14:39
It's time for a BIG update!

After a month of stewing over decompressor outputs and tech papers, I finally learned enough about MP3s to make an actual compression optimizer (sort of like rehuff for Vorbis).

Using the new -z switch in 1.10 will enable a brute-force Huffman optimization which slightly improves overall compression at the loss of quite a bit of speed. How much it helps is highly dependant on the encoder. LAME encodes tend to be ~0.02% smaller (ie. don't bother  ) but I've gotten a 10% improvement over the normal mp3packer output for some files (unknown encoders...) (*)

The -z switch will not help with MPEG2 / 2.5 audio, or short blocks (I don't really feel the need to include support for them) and it is fairly intolerant to errors. If you see a line that looks like this:
Code: [Select]
WARNING: recompression error on frame 10862
it means that the recompression of that frame was thrown out and the input data was used instead, as though -z was not specified.


Also added was support for directories (at last  ) and support for deleting files.

The new switches for deleting files are:
Code: [Select]
--keep-ok (out | both)
--keep-bad (in | out | both)

The first is used for every file which did not report a sync or buffer error. If you set it to "out" it will only keep the output file, and delete the input file.
The second is used in the rest of the files (the ones which did have errors). Using "in" will leave only the input file, and not write an output.

A few examples:
Code: [Select]
--keep-ok both --keep-bad both
This is the default. It keeps both input and output files in all cases.
Code: [Select]
--keep-ok out --keep-bad in
This will essentially move and repack the error-free files, while leaving the files with errors alone.
Code: [Select]
-u --keep-ok out --keep-bad in
Same as previous, but it will move the files with errors and repack the other files in-place.
Code: [Select]
-u --keep-ok out --keep-bad out
This will replace every file with its repacked version.

Note that, as stated before, a recompression error is actually just a warning. A file with only recompression errors will be covered under the --keep-ok option.


(*) I actually got an 83% savings over the regular repacker with one file, but the file itself was mostly digital silence put through a braindead encoder. That file was why I originally made the -z switch in 1.04
Title: MP3 repacker
Post by: moozooh on 2006-09-29 12:56:13
Very good work, Omion. Now I manage to save a few kbps on every 320 kbps file I have.
Title: MP3 repacker
Post by: bukem on 2006-09-29 14:11:16
Great job Omion! I'm going to test it tonight.

Edit: The links to the newest version of mp3packer doesn't work 
Title: MP3 repacker
Post by: Omion on 2006-09-29 18:04:06
The links to the newest version of mp3packer doesn't work 

Sorry about the hosting issues. Looks like my router is down. Unfortunately I'm at work right now, so I can't do anything, but it should be up in a few hours.
Title: MP3 repacker
Post by: Omion on 2006-09-30 03:42:40
OK. I just got back. The links should work now.

It looks like my router didn't update the dyndns IP, so the DNS entry was wrong. Sorry about that!
Title: MP3 repacker
Post by: Gnerma on 2006-09-30 07:32:43
This is a really, really awesome update Omion thanks a lot. I appreciate all the effort you put into it, it really is a huge improvement. Many albums that yielded only a couple kb before will give up 20-50 now.

Have you tested the new -z on iTunes encodes? I realize that this isn't a particularly good MP3 encoder, but its output seems to be broken out of the box. As in, loads of recompression errors on a fresh file. EDIT - BUT the recompressed files do pass bit-compare
Title: MP3 repacker
Post by: Omion on 2006-09-30 07:47:06
Have you tested the new -z on iTunes encodes? I realize that this isn't a particularly good MP3 encoder, but its output seems to be broken out of the box. As in, loads of recompression errors on a fresh file.

I haven't tested it yet. I'll get to it as soon as I can.
[edit: yeah, recompression errors galore. I'll fix it as soon as I can (probably late tomorrow)]


@all: it would probably be a good idea to use Foobar to make sure the output with the -z switch is the same as without, at least for now. I'm always surprised by how many encoders break my program
Title: MP3 repacker
Post by: Rain on 2006-09-30 09:33:02
Yes! Full directory packing 
Title: MP3 repacker
Post by: Ojay on 2006-09-30 11:26:29
@Omion: many Thanks for this program. For me it rapidly became the most important tool to directly edit MP3 files without needing to decode them. This has reasons and I just want to point you to a possibility how to use this program you probably haven't heard about.

I am a little bit of a 5.1 surround sound whore at the moment and I am converting all my MP3 files (mostly music radio shows especially from internet streaming) to MP3 Surround. That is done with the new Fraunhofer MP3SX converter and the final 5.1 quality is quite impressive (at least for me). The converter adds a third channel to any stereo MP3 file (the surround channel) without decoding just by rebuilding the MP3 bitstream. However, all the stereo files I own are CBR-encoded files only. This means that the third surround channel adds some bitrate to the file to store the surround info (actually always a constant amount of 15kbps for each file) but - unfortunately- the upgraded file needs to fit the CBR specifications (only 128,160,192,224,256 and 320kbps are defined for CBR). This means that a 192kbps CBR file will become a 224kbps CBR MP3 file after adding the surround channel. So 17kbps of these additional 32kbps are wasted as the surround data would fit into 15kbps.

At that point it is really useful to use mp3packer (before converting stereo MP3 to MP3 Surround). That removes any buffer and sync errors (required for the conversion as internet streams always show some errors and the converter does not accept MP3 streams with errors), makes the files slightly smaller (of course), and converts them to VBR. This conversion to VBR is especially charming as the MP3SX converter now does not need to increase the file size in 32kbps steps as before but just adds only the really needed 15kbps to the VBR file.

For a 2hour radio show that finally saves about 18MB (!) of hard disk space for a VBR file when compared to CBR.

So, many thanks again for this program!

(Edit: would be nice if mp3packer would recognize the MP3Surround structures in some way - maybe even smaller file sizes might be possible)
Title: MP3 repacker
Post by: Omion on 2006-09-30 16:31:44
@Ojay: Thanks for the response!

(Edit: would be nice if mp3packer would recognize the MP3Surround structures in some way - maybe even smaller file sizes might be possible)

I was thinking about adding that, but up until your post I didn't know if there was a free way to create MP3 surround bitstreams. I'll see if it's easy to make mp3packer not delete the extra info.

I also found out what was wrong with the iTunes encodes, although I'm not sure why it didn't happen with other encoders. I'll fix it when I get back from work. (yes, I work on Saturday...)
Title: MP3 repacker
Post by: Omion on 2006-10-01 07:51:42
1.11 is out, and should fix the iTunes issue.

The problem was that if the two highest frequency bands actually contained data, there was a 50% chance that writing that data would result in an out-of-bounds array access. It was fixed by forcing everything to the 50% that worked 

Only iTunes triggered it because apparently only iTunes thinks that tiny values of >22KHz audio is worth saving. Everything with a working psy model throws it out
Title: MP3 repacker
Post by: bukem on 2006-10-01 11:06:08
@Omion

It seems that links doesn't work again 
Title: MP3 repacker
Post by: Gnerma on 2006-10-01 11:16:08
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?
Title: MP3 repacker
Post by: Omion on 2006-10-01 17:32:18
@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.
Title: MP3 repacker
Post by: abramx on 2006-10-01 18:33:03
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?
Title: MP3 repacker
Post by: bukem on 2006-10-01 18:55:01
@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.
Title: MP3 repacker
Post by: Synthetic Soul on 2006-10-01 19:04:58
To confirm: I couldn't access either this morning.
Title: MP3 repacker
Post by: Rain on 2006-10-02 10:55:26
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.
Title: MP3 repacker
Post by: Omion on 2006-10-04 20:53:00
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.

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.
Title: MP3 repacker
Post by: bukem on 2006-10-11 23:42:06
@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!!!
Title: MP3 repacker
Post by: riggits on 2006-10-17 19:14:42
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 (http://rapidshare.de/files/37112648/04_Hora.mp3)

And the resulting files claim to have a bitrate of 64kbps.
Title: MP3 repacker
Post by: Gnerma on 2006-10-17 19:51:10
You need to use the -z switch riggits:

Original - 10,347,388
Default - 10,347,596
With -z - 8,812,548
Title: MP3 repacker
Post by: riggits on 2006-10-17 19:56:30
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.
Title: MP3 repacker
Post by: bukem on 2006-10-17 21:02:15
@Omion

Hi there! I've found another mp3 track (http://rapidshare.de/files/37125260/01._was_a_bee_-_this_is_what_you_are.mp3.html)  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
Title: MP3 repacker
Post by: Firon on 2006-10-17 21:06:09
what the heck do you do to your MP3s, bukem?
Title: MP3 repacker
Post by: Omion on 2006-10-17 21:21:06
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?
Title: MP3 repacker
Post by: Omion on 2006-10-17 22:10:54
@Omion

Hi there! I've found another mp3 track (http://rapidshare.de/files/37125260/01._was_a_bee_-_this_is_what_you_are.mp3.html)  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.
Title: MP3 repacker
Post by: bukem on 2006-10-17 22:24:14
@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
Title: MP3 repacker
Post by: Omion on 2006-10-18 01:44:26
@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!
Title: MP3 repacker
Post by: jaybeee on 2006-10-18 08:49:21
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 (http://omion.dyndns.org/mp3packer/mp3packer.html) for a while now? - I must've missed it...

---

What other program you working on Omion?
Title: MP3 repacker
Post by: Omion on 2006-10-18 19:18:30
Have you had your website (http://omion.dyndns.org/mp3packer/mp3packer.html) 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.

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.
Title: MP3 repacker
Post by: Firon on 2006-10-21 22:29:00
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...
Title: MP3 repacker
Post by: dv1989 on 2006-10-22 10:34:22
Let's just hope that he doesn't read this.
Title: MP3 repacker
Post by: psyllium on 2006-10-22 13:26:40
I have (finally) released a new version of WinMP3Packer to handle some of the extra options in mp3packer.exe. The thread is here (http://winmp3packer.webhop.net).
Title: MP3 repacker
Post by: Antonski on 2006-10-24 01:35:39
@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
Title: MP3 repacker
Post by: Omion on 2006-10-24 05:13:42
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 

@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.
Title: MP3 repacker
Post by: jaybeee on 2006-10-24 08:22:10
^^ 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?
Title: MP3 repacker
Post by: _mik on 2006-10-28 13:06:55
The mp3packer is really good, but could you add a small feature to it ? It would be great to convert mp3 from stereo to mono, by removing one channel (either left or right for dual channel, side channel for mid side stereo, or maybe also removing the panning info from itensity stereo frames).

I have a bunch of badly recorded mp3s. They are m/s stereo CBR, but one channel is silent, so i guess the side channel equals +/-mid channel. It is very annoying to hear them on stereo headphones. I would like to convert them to mono losslessly (not counting loosing the side channel , but that's my point).

Thanks in advance,
mik
Title: MP3 repacker
Post by: Omion on 2006-10-29 00:45:12
That would work OK for dual-channel or simple stereo, but joint stereo would be quite a bit harder. The problem is that joint stereo means that each frame can be encoded in either L/R stereo or M/S stereo. I could easily take out the first channel in every frame, but that would switch between taking out the side channel and taking out the right channel.

Depending on how the scalefactors work, I may be able to mix the left and right channels perfectly (*), but that depends on me figuring out scalefactors 

I'll probably be able to look into it soon, as I think I can get my other program out the door sometime in the very near future.

(*) obviously, this wouldn't be lossless at all, but I should be able to make it mathematically perfect ((L+R)/2)
Title: MP3 repacker
Post by: _mik on 2006-10-30 16:46:38
That would work OK for dual-channel or simple stereo, but joint stereo would be quite a bit harder. The problem is that joint stereo means that each frame can be encoded in either L/R stereo or M/S stereo. I could easily take out the first channel in every frame, but that would switch between taking out the side channel and taking out the right channel.

My files (although they are joint stereo) have all frames indicated as ss (in EncSpot), so they are L/R stereo (if I understand correctly EncSpot's details window). They were recorded using an iRiver from a mic amplifier.

Depending on how the scalefactors work, I may be able to mix the left and right channels perfectly (*), but that depends on me figuring out scalefactors

(*) obviously, this wouldn't be lossless at all, but I should be able to make it mathematically perfect ((L+R)/2)

Hmm, I've heard some people saying it's impossible

On the other side, you could also add a possibility to extract L or R channel from M/S stereo frames using (M+S) or (M-S) formula.

In my case I would prefer extracting L or R, because the other channel is silent. Doing (L+R)/2 will mix noise from the silent channel and will lower overall signal level (because of dividing by 2).

mik
Title: MP3 repacker
Post by: Omion on 2006-10-31 05:54:24
Hmm, I've heard some people saying it's impossible

I just finished looking at the scalefactor code and... yup. Impossible.  If scalefactors went in powers of 2 it would be OK, but it looks like they go in powers of 2^0.25, which makes it impossible for just about every case.

Quote
On the other side, you could also add a possibility to extract L or R channel from M/S stereo frames using (M+S) or (M-S) formula.

In my case I would prefer extracting L or R, because the other channel is silent. Doing (L+R)/2 will mix noise from the silent channel and will lower overall signal level (because of dividing by 2).

mik

For joint stereo, that would be exactly as impossible as mixing stereo to mono. For simple stereo, though, it should be quite easy. But are your files joint stereo? I don't want to make something that wouldn't be of any use at all 

(Note that when I say impossible, I mean it will be impossible to do it losslessly. It is, of course, quite easy to do in an audio editor)
Title: MP3 repacker
Post by: _mik on 2006-10-31 09:55:28
I just finished looking at the scalefactor code and... yup. Impossible.  If scalefactors went in powers of 2 it would be OK, but it looks like they go in powers of 2^0.25, which makes it impossible for just about every case.

, but 2 = (2^0.25)^4, isn't it?

You could still do the thing I requested at the beginning, i.e. keep L or R for L/R frames (selected via a cmdline switch), or M for M/S frames. This should sound ok, if a mono source was recorded to both channels (M=L=R=(L+R)/2).

For joint stereo, that would be exactly as impossible as mixing stereo to mono. For simple stereo, though, it should be quite easy. But are your files joint stereo? I don't want to make something that wouldn't be of any use at all

As I already said, my files are marked as joint stereo, but 100% frames are ss in EncSpot (= L/R, I guess).

mik
Title: MP3 repacker
Post by: Omion on 2006-10-31 16:24:55
I just finished looking at the scalefactor code and... yup. Impossible.  If scalefactors went in powers of 2 it would be OK, but it looks like they go in powers of 2^0.25, which makes it impossible for just about every case.

, but 2 = (2^0.25)^4, isn't it?

Although you're right, it doesn't quite work, unfortunately.

Here's why:
The only way to mix the two channels would be to change the scalefactors so that they're equal, then combine the scaled samples.
The change in the scalefactor (?) is always going to be the inverse of the change in the scaled sample in order for them to be equal in the end. real_sample = scalefactor * scaled_sample = (scalefactor / ?) * (scaled_sample * ?)
Since the scaled sample must be an integer, ? must also be an integer, which means it cannot go in small enough steps to make it accurate.

Here's a little example:
Let's say the left channel has scalefactor 2, and the right channel has scalefactor 2^0.5 (1.414..., an irrational number). We need to find integers ?L and ?R such that:
2 * ?L = 2^0.5 * ?R
?L and ?R will always be integers, so 2 * ?L is an integer.
But 2^0.5 is irrational, and an integer times an irrational number is always irrational.
So we have:
{some integer} = {some irrational number}
which will never happen.
Therefore, in order to work, ?L and ?R cannot be constrained to integers, meaning that the output sample will not be an integer, which it must be in order to be stored.

I hope that made some sense... 

Quote
You could still do the thing I requested at the beginning, i.e. keep L or R for L/R frames (selected via a cmdline switch), or M for M/S frames. This should sound ok, if a mono source was recorded to both channels (M=L=R=(L+R)/2).

If it's a mono source, it will sound great. For a stereo source it may sound highly odd. But it looks like, in your case at least, this will work.

Quote
As I already said, my files are marked as joint stereo, but 100% frames are ss in EncSpot (= L/R, I guess).

mik

Great. Then there will be no problem. I'll get to work on it when I find the time
Title: MP3 repacker
Post by: SebastianG on 2006-10-31 18:07:55
Requantization is always required when mixing channels regardless of how the scalefactors are because of the non-linear quantizer MP3 uses.
Title: MP3 repacker
Post by: Omion on 2006-10-31 18:39:02
Heh. I hadn't even looked that far into the decoding, but you're right that that makes completely impossible anyway.
Title: MP3 repacker
Post by: _mik on 2006-11-02 13:41:44
I have another question: is there a possibility to change volume of a whole mp3 losslessly? I know I can use replaygain, but it works with only a few programs. Maybe scalefactors will do the thing, or something like global gain? If so, mp3packer could have such a feature .

mik
Title: MP3 repacker
Post by: bukem on 2006-11-02 13:50:09
@mik:

I guess that what are you looking for is simply mp3gain (http://mp3gain.sourceforge.net/)
Title: MP3 repacker
Post by: _mik on 2006-11-02 14:16:53
Yeah, you're right, bukem. Thanks .

mik
Title: MP3 repacker
Post by: Omion on 2006-11-02 15:29:35
Well, it looks like the "extract first channel" won't be done any time soon. There are just too many places where I assume that the input type is the same as the output type (especially with regard to the number of channels) Sorry!
Title: MP3 repacker
Post by: M on 2006-11-02 16:20:57
Omion, In my foobar2000 playlist view, I set the "Technical" column to show codec, bitrate and tagtype, as well as whether or not the MP3 uses "Accurate Length" info:
Code: [Select]
$if($info(mp3_accurate_length),◦ )%codec% '[' %bitrate% kbps [· $info(tagtype)]']'

Now, on one of my old albums I had a single track that was damaged; I replaced it with an MP3 from an alternate source, and used mp3packer to match the CBR bitrate to the rest of the album (no technical advantage... I just liked seeing a consistent bitrate through the album, without one track jumping up and down saying, "I'm different!").

The old album had been encoded without any sort of "Accurate Length" tag, but the repacked version is showing its presence. I've already tested by repacking the entire album, and the "◦" indicator appears consistently where it was not present before, so I'm assuming mp3packer is simply adding a L.A.M.E. tag and indicating the possibility of a sample offset without currently calculating one. Correct?

If this is the case, would it be possible to add the capability (or add a switch, if need be) to parse silence within the MP3 file and guesstimate to appropriate sample offset - as iTunes apparently now attempts to do - so that this pseudo-"Accurate Length" info could be doing something useful? Please?

    - M.
Title: MP3 repacker
Post by: Omion on 2006-11-03 00:21:35
That is weird. 

I did a test and, sure enough, Foobar flags it as "accurate" What I don't understand is where Foobar gets that idea...

mp3packer will only write the delay data if it finds it in the input file. (It uses an XING tag by default, and only uses a LAME tag if one was found in the input)

Foobar is doing something odd. If it actually did have sample-accurate length, the tags <ENC_DELAY> and <ENC_PADDING> would show up in the properties, right above <MP3_ACCURATE_LENGTH>. On the mp3packer output, <MP3_ACCURATE_LENGTH> is set, but neither <ENC_DELAY> nor <ENC_PADDING> are.

I think Foobar has a different idea of "accurate length" than either of us do. Perhaps "accurate length" means that the number of mp3 samples is known without reading the whole file?

I think you can change your code to something like:
Code: [Select]
$if($and($info(enc_delay),$info(enc_padding)),◦ )

That should get you the info you want.

Your idea to add the padding data would be very handy, but it would require a lot of work on my part. I would need to make an entire mp3 decoder in order to get at the actual samples. Currently, mp3packer only dequantizes the frequency coefficients, and that was hard enough to get working!
Title: MP3 repacker
Post by: M on 2006-11-03 03:54:55
Yes, weird. 

The code change you suggested does indeed accomplish what I was attempting, and in a slightly more elegant manner, by eliminating those false positives. Thank you.

What would be the feasibility of parsing the frame/sample info to an existing, open-source decoder? Would that even be a possible solution, and if so, worth pursuing? Admittedly, the best solution to accomplish "Accurate Length"-style gapless performance will always be a clean encode, although I can imagine situations when that might not be as easily accomplished as one might desire.

    - M.
Title: MP3 repacker
Post by: j7n on 2006-11-24 21:07:24
This is a quite useful tool. But why do you fill the unused space with the title of your proggie? It is hard to visualize silent frames after running the file through Mp3Repacker.
Title: MP3 repacker
Post by: Omion on 2006-11-25 01:14:17
Eh... I fill it with the title because I have to fill it with something. Most people don't see it, and sometimes there's nowhere else to put the name of the program.

Is it that much harder to visualize it as silence than a string of nulls? Every hex editor that I've run across has an ASCII view right next to it. More "mp3packer1.13-145" means more silent
Title: MP3 repacker
Post by: j7n on 2006-12-09 14:36:05
I visualize it this way.. Repeated bytes of any value, no matter 0x00 or 0x55 = silence. Otherwise it's a signal. BTW, never mind: already replaced both strings in the exe.

How can one be sure that Mp3Repacker is lossless? I am using it with the -z option (so that it actually does something).

- Could I assume everything went right if there were no error msgs?
Title: MP3 repacker
Post by: Firon on 2006-12-09 15:25:54
do a bit comparison with the original file. If it's the same, it was lossless.
Title: MP3 repacker
Post by: Omion on 2006-12-10 05:44:09
BTW, never mind: already replaced both strings in the exe.

Heh. I didn't think of that 
Note, however, that the version string is also used in the help output. Not really a big deal, though.

Quote
How can one be sure that Mp3Repacker is lossless? I am using it with the -z option (so that it actually does something).

I have the best success with Foobar's "bit compare files" option.
[edit: Firon beat me to it. I should really try to take less than 14 hours to write my responses  ]

Quote
- Could I assume everything went right if there were no error msgs?

Probably.  I haven't found any losses with valid input files, but that doesn't mean that there are no problems. If you have any concerns, run the files through Foobar. Then post here if any files don't give warnings but fail Foobar's test.
Title: MP3 repacker
Post by: Martin F. on 2006-12-29 03:06:40
I got an error …

Quote
mp3packer.exe -z "C:\Dokumente und Einstellungen\Martin\Desktop\dimitris-08-not-human.mp3"

*** 'C:/Dokumente und Einstellungen/Martin/Desktop/dimitris-08-not-human.mp3' ->
'C:/Dokumente und Einstellungen/Martin/Desktop/dimitris-08-not-human-vbr.mp3'
WARNING: error recompressing frame 10: Invalid_argument(index out of bounds)
100% done with 15174 frames

The file can be downloaded using this torrent: http://www.legaltorrents.com/bit/dimitris-...hythmos.torrent (http://www.legaltorrents.com/bit/dimitris-collages-rhythmos.torrent) (µTorrent lets you download individual files)
Is that an error in mp3packer or in the file?

Anyway, great program, thanks
Title: MP3 repacker
Post by: Omion on 2006-12-29 05:07:08
Is that an error in mp3packer or in the file?

It is most likely an error in the file which is triggering an error in the program. But the program shouldn't give that error at all. I'll see what's up.

[edit: Actually, that error means that the -z option failed, so it was not used for that frame. The files are still bit-identical, though]
Title: MP3 repacker
Post by: bukem on 2007-01-05 02:58:06
@Omion:
I've spotted several times the same kind of warnings that Martin F. pointed out in his post but because the bitcompare doesn't show any differences I didn't reported it to you. By the way - I've processed don't-know-how-many-in-fact mp3 files since last time we spoke without any problems so far 

Edit: don't-know-how-many-in-fact ~ circa 5000 files
Title: MP3 repacker
Post by: Omion on 2007-01-05 03:44:25
Yeah, that message is really not an issue. The it's really just a warning, not an error (even though it says "error" in it)

I changed my working version to have less alarming warning messages (especially that one), but I decided that it wasn't worth it to actually release an update.
Title: MP3 repacker
Post by: halb27 on 2007-01-05 08:15:58
... I've processed don't-know-how-many-in-fact mp3 files since last time we spoke without any problems so far  ...

As you have a lot of practical experience: can you report about your results please?
What encoder did you use which way before repacking? What is the average filesize improvement?

Background for my question: I know the repacker brought an essential improvement for Lame 3.97b1 encoded files but after bit reservoir was reinstuituted with b2 I had the impression that the repacker isn't that useful as it was before. However I see the repacker is still being used actively, so I'd like to learn about its current usage and properties.
Title: MP3 repacker
Post by: j7n on 2007-01-05 08:47:06
I think the repacker is mostly useless for files you encode today with LAME. Its useful for files other people have encoded before. To estimate the size decrease if repacked (-z), check your MPEG Layer-3 file with a hex editor. Padding data is usually written as 0x00 or 0xFF and visible as empty space inside the file. For such files I have decreased the avg bitrate from 320 to 250 kBit/s.
Title: MP3 repacker
Post by: halb27 on 2007-01-05 08:54:27
I think the repacker is mostly useless for files you encode today with LAME. Its useful for files other people have encoded before. To estimate the size decrease if repacked (-z), check your MPEG Layer-3 file with a hex editor. Padding data is usually written as 0x00 or 0xFF and visible as empty space inside the file. For such files I have decreased the avg bitrate from 320 to 250 kBit/s.

I see. Bitrate decrease is great. I didn't think of other peoples' encodings but do it myself - streamripped internet mp3 at high bitrate (usually 192 to 256 kbps). So the repacker may be useful to me too.
Title: MP3 repacker
Post by: bukem on 2007-01-05 15:01:29
@halb27:
As j7n already mentioned you can't expect a big bitrate decrease when compressing LAME VBR (from my experience for LAME VBR (in fact any VBR) you get 1~3% decrease). The main reason I'm using mp3packer is to convert high bitrate CBR (~256 and more) to VBR which allows me to save around 10~15% of size which is precious for my portable mp3 player, but that of course is not a rule. In some rare cases I was able to save even 30~40% especially when I was mp3packing 320 CBR mp3 with contemplation/meditation music which tends to have long silence periods. Other reason why I'm using mp3packer is to rebuild broken/bad mp3 - I know that it's not main purpose of that tool but it came to be very efficient for repairing synchronization errors and etc.
Title: MP3 repacker
Post by: halb27 on 2007-01-05 15:56:43
Thanks a lot, bukem and j7n. I will use mp3repacker on those internet radio streamripped files which I want to keep.
Title: MP3 repacker
Post by: Martin F. on 2007-01-20 20:10:20
On this (http://web286.login-4.hoststar.at/bilder/8_buffer_errors.mp3) file, mp3packer reports that there were 8 buffer errors, but it displays only one.
Quote
>mp3packer -z 8_buffer_errors.mp3

*** '8_buffer_errors.mp3' -> '8_buffer_errors-vbr.mp3'
WARNING: buffer underflow; frame 0 will be entirely replaced with silence
100% done with 334 frames

WARNING: There were 8 buffer errors
Title: MP3 repacker
Post by: Light-Fire on 2007-01-20 21:30:13
It is a good software to convert VBR files to equivalent CBR to use with players that don't work well with VBR.
Title: MP3 repacker
Post by: Omion on 2007-01-21 02:34:25
@Martin F.:

It looks like there is a bit of a discrepancy in what mp3packer thinks is a buffer error.It would seem that 1 would imply 2; however, if the frame's data starts outside the buffer but the data has 0 length, the number of errors will be incremented but there will be no data loss.

I think I'll change it so it only counts an error if there was data loss. I'll fix that ASAP.


It is a good software to convert VBR files to equivalent CBR to use with players that don't work well with VBR.

Thanks! A lot of people seem to use mp3packer for that.
Title: MP3 repacker
Post by: Omion on 2007-01-21 04:29:51
1.14 is out.

The output issues that Martin F. raised have been fixed. The repacker itself was not changed.

Get it at the beginning of this thread.
Title: MP3 repacker
Post by: bukem on 2007-02-18 17:32:28
@Omion:

Found another mp3 that crashes mp3packer (v1.14-159):

Quote
*** 'volume 10/07. j. dilla - walkinonit.mp3' -> 'volume 10.new/07. j. dilla - walkinonit.mp3'
WARNING: sync error; expected frame 1 at 1586
WARNING: recompression skipped on frame 1: Invalid_argument(index out of bounds)
100% done with 1 frames

WARNING: There was 1 sync error
Fatal error: exception Mp3types.Too_many_bytes


You should get that file in your mailbox right now. Greets.
Title: MP3 repacker
Post by: Omion on 2007-02-18 23:10:16
@bukem:

Thanks for the file. It looks like the first frame has the "original" bit set, but no other frames have it. Then it randomly finds another frame which overflows. I took off the original-bit checking for valid frames, and it seems to work for that file. I'll put out a release soon.

(In the meantime, you can set byte 544 to 0x00 in that file and it will work, but that's not really a generalizable solution  )
Title: MP3 repacker
Post by: Omion on 2007-02-19 02:34:33
OK. Released 1.15. I just made it so that mp3packer does not check for the same "original" bit throughout the entire file. I've never heard of this being a problem until bukem's sample, though.

Nothing else wan changed. In fact, the entire change to the code was 6 bytes, whereas I had to add ~130 bytes to the changelog
Title: MP3 repacker
Post by: bukem on 2007-02-19 17:21:28
OK. Released 1.15. I just made it so that mp3packer does not check for the same "original" bit throughout the entire file. I've never heard of this being a problem until bukem's sample, though.

Nothing else wan changed. In fact, the entire change to the code was 6 bytes, whereas I had to add ~130 bytes to the changelog


I'm bad a.s - nothing but problems . Thanks for quick response. Be back soon 

EDIT:
I'm getting a lot of following errors on one album - is it any bad?
Code: [Select]
WARNING: error decompressing frame 1880; copying frame data instead
WARNING: error decompressing frame 1881; copying frame data instead
WARNING: error decompressing frame 1882; copying frame data instead
WARNING: error decompressing frame 1891; copying frame data instead
WARNING: error decompressing frame 1902; copying frame data instead
WARNING: error decompressing frame 1909; copying frame data instead
WARNING: error decompressing frame 1915; copying frame data instead
WARNING: error decompressing frame 1921; copying frame data instead
WARNING: error decompressing frame 1935; copying frame data instead
WARNING: error decompressing frame 1940; copying frame data instead
WARNING: error decompressing frame 1956; copying frame data instead
WARNING: error decompressing frame 1957; copying frame data instead
WARNING: error decompressing frame 1962; copying frame data instead
Title: MP3 repacker
Post by: Omion on 2007-02-20 02:34:33
EDIT:
I'm getting a lot of following errors on one album - is it any bad?

That means that the MP3 data was bad. Repacking it will not make it any worse though, since the data was just passed unmodified.
Title: MP3 repacker
Post by: j7n on 2007-02-20 15:46:28
I have a similar question...

On some Blade-encoded files (the ones Mp3Packer is useful on) your program sometimes gives me these error msgs:

Quote
WARNING: bitstream error on frame %d.

Quote
WARNING: error recompressing frame %d: Invalid_argument(%s)


The output files play ok though. What do these warnings mean?
Title: MP3 repacker
Post by: stigc on 2007-02-20 18:10:49
I don't get the -z flag. Is it loss-less?
Title: MP3 repacker
Post by: Omion on 2007-02-20 19:28:44
@j7n:
Those warnings are the pre-1.14 versions of the ones bukem was getting. It means that there was a problem in decompressing the actual frame data, so the -z switch was turned off for that frame. The data should still be exactly the same (even though it may not have been valid in the first place)

I don't get the -z flag. Is it loss-less?

Yes, it's lossless. The -z switch is equivalent to unpacking a .zip file, and re-packing it with a higher compression level.
Title: MP3 repacker
Post by: maadjordan on 2007-03-02 08:47:55
thanks OMION for this masterpeiece.. but what i request is somthing else

i would request to add the first phase of -z command which is to decode the huffs of the frame  into expanded mp3 form and a feature to restore or repack it like -z command to that format type.. in order to test the possiblity to achieve even more compression ratio via lossless programs like winrar and 7-zip so if worked it would be great.. and if the resulted file would be mp3 readable to any decoder then it could be used with any player that support packed music files aka foobar..

So please add this necessary feature to test this capability..even in a special build.. Thanks in advance for the Mp3packer and speicaly for the -z command..

is there going to be OGGpacker ?? on cbr files which is rare not like mp3 and has a huffman coding.. to retest
Title: MP3 repacker
Post by: j7n on 2007-03-09 06:15:46
Quote
is there going to be OGGpacker ??

I believe there is not even a good cutter for OggS. It's a big advantage of classic MPEG formats, that there is no file header required and any sequence of frames can be decoded.



I've found a problem file where Mp3Packer fails to skip garbage at the beginning.
Code: [Select]
*** 'D:/_temp/dcfinal/1996 - Around the World Hit Singles - the Journey So Far/0
2_Deep.mp3' -> 'D:/_temp/dcfinal/1996 - Around the World Hit Singles - the Journ
ey So Far/02_Deep-vbr.mp3'
WARNING: buffer under AND overflow; frame 0 is garbage and will be replaced by s
ilence
WARNING: sync error; expected frame 1 at 721
WARNING: buffer overflow; frame 1 will be truncated
WARNING: sync error; expected frame 2 at 2065
WARNING: buffer overflow; frame 2 will be truncated
WARNING: sync error; expected frame 3 at 3409
WARNING: buffer overflow; frame 3 will be truncated
WARNING: sync error; expected frame 4 at 1521790
WARNING: buffer overflow; frame 4 will be truncated
WARNING: sync error; expected frame 5 at 2708486
WARNING: buffer overflow; frame 5 will be truncated
WARNING: sync error; expected frame 6 at 6864529
WARNING: buffer overflow; frame 6 will be truncated
WARNING: sync error; expected frame 7 at 6865873
WARNING: buffer overflow; frame 7 will be truncated
WARNING: sync error; expected frame 8 at 6867217
WARNING: buffer overflow; frame 8 will be truncated
100% done with 8 frames

WARNING: There were 9 buffer errors and 8 sync errors

The output 02_Deep-vbr.mp3 is 2040 bytes long. It happens that the first 2 bytes of the input file look like a valid MPEG Layer 3 frame with CRC error detection (i.e. FF FA), but in fact this turned out to be a random occurence in the first (incomplete) frame. I believe the first frame got cut because of removal of a bogus ID3v2 header, but that's not really important.
Title: MP3 repacker
Post by: Omion on 2007-03-09 15:57:18
thanks OMION for this masterpeiece.. but what i request is somthing else

i would request to add the first phase of -z command which is to decode the huffs of the frame  into expanded mp3 form and a feature to restore or repack it like -z command to that format type.. in order to test the possiblity to achieve even more compression ratio via lossless programs like winrar and 7-zip so if worked it would be great.. and if the resulted file would be mp3 readable to any decoder then it could be used with any player that support packed music files aka foobar..

So please add this necessary feature to test this capability..even in a special build.. Thanks in advance for the Mp3packer and speicaly for the -z command..

is there going to be OGGpacker ?? on cbr files which is rare not like mp3 and has a huffman coding.. to retest

I'm afraid I don't quite follow you here. You want to be able to store the decompressed frequency values in the hope that you could apply your own compressor to the values?

If that is the case, it's quite impossible that it would be able to be decoded by normal mp3 players, even with archive support. When you unpacked the archive, you would end up with... decompressed frequency values, which does not make for a valid MP3 file.

The only way it could work is if I made mp3packer artificially inflate the Huffman values, in the hope that the archive format would pick up the compression better. It would be a valid mp3, but not compressed as much. This is possible, but I highly doubt that it will result in any improvement.

As for OggPacker, I'm not going to write it. Learning everything there is to know about one audio format is enough for me. (Learning about mp3 actually was my primary goal of this program; I hardly have any mp3s in my collection...) There was a program by Garf (I think) which optimized the Huffman tables in a Vorbis stream, but I seem to remember it being somewhat buggy.


@j7n:

Yeah. That's because mp3packer only checks one frame to see if it's valid, rather than making sure there's another valid frame which follows directly after it. That little shortcut has been nagging at me for quite a while, but there's no easy fix for it other than to completely re-make the mp3 reading portion of the program.
Rewriting large parts of mp3packer is not out of the question -- I've done it twice before -- but now that I've got a full-time job and another program out to support, my time is stretching thin(*) A fix should happen... eventually. No idea when, though.

In the mean time, use a hex editor to delete the fake sync pattern. You seem to know what you're doing  Other than that, I don't really know what can be done.

(*) especially now that I've been re-playing Oblivion. Man, that game takes a lot of time.
Title: MP3 repacker
Post by: j7n on 2007-03-09 19:20:53
It's no problem.
Title: MP3 repacker
Post by: RogerG on 2007-03-10 02:17:38
Hi!

nice application!
- sometimes out is larger than in. Could you make an option to not overwrite in if out is larger?
- What do you think about an option to remove space padding from id3v2 tags? This would decrease file size even more.
- What will happen to my file if there are buffer errors?
- Why does it corrupt my files ("buffer underflow; frame 0 will be truncated", "WARNING: buffer underflow; frame 0 will be entirely replaced with silence") ? Not sure if it does but the warnung messages don't sound well. How can your program be lossless if it inserts silence into my files?

Maybe you can make a small FAQ

Regrads
Title: MP3 repacker
Post by: Omion on 2007-03-10 05:47:31
sometimes out is larger than in. Could you make an option to not overwrite in if out is larger?
The only time the output is larger than the input should be when the only thing that's added is the LAME header. In this case the file is only ~500 bytes larger. I suppose that any increase is bad, but I figured that 500 bytes is not enough to worry about. I can look into not using the output file if it's larger, but if it's hard I don't think I'll bother. 

Have you seen any files that get larger than about 500 bytes? If so, then that's probably a bug.

Quote
What do you think about an option to remove space padding from id3v2 tags? This would decrease file size even more.
I try to avoid id3 tags altogether, especially id3v2. It's quite a nasty tagging spec, and judging by the files that I get, it tends to get broken quite a bit. (And I'd have to implement yet another CRC generator... not fun)

Quote
What will happen to my file if there are buffer errors?
That depends on what options you have set. By default both the output and input files will be kept, and a warning will be displayed. If you change the --keep-bad option, various things happen:
--keep-bad in: Keeps only the input file. Good for only repacking the files without errors
--keep-bad out: Keeps only the output file. Good if you want to repack all the files no matter what
--keep-bad both: Default. Won't delete either file.
Similarly, the --keep-ok switch determines which files to keep when no errors occur.
Note also that if you use the -u switch, the output file will be the same name as the original input, whereas the input file will be renamed something else.

Quote
Why does it corrupt my files ("buffer underflow; frame 0 will be truncated", "WARNING: buffer underflow; frame 0 will be entirely replaced with silence") ? Not sure if it does but the warnung messages don't sound well. How can your program be lossless if it inserts silence into my files?
That warning, when you see it only on the first few frames, generally means that the file was split improperly. The data for that frame doesn't exist in the file, so the only thing that can be done to make it normal again is replace it with a frame which is silent.

The warning message is telling you that the input file is bad, not that the processing did something horrible to the file.

When a bitstream error occurs, you are right that mp3packer is no longer lossless on that frame, but only because the data is already lost and mp3packer has to "recreate" it.
For example, if half of a frame is cut off, you can do a few things:There is basically no "lossless" way to even read the mp3 data, as some of it is already lost!

However, all frames which do not produce a warning message should be lossless. If not, there's something wrong.
Title: MP3 repacker
Post by: Martin F. on 2007-03-19 15:21:36
mp3packer -z 8bp026-05-sabastian_boaz-cold_hard_fusion.mp3 (http://ftp://ftp.scene.org/pub/music/groups/8bitpeoples/8bp026-05-sabastian_boaz-cold_hard_fusion.mp3)
Quote
WARNING: error decompressing frame 57; copying frame data instead

How can the new file be without decompressing errors if the data is simply copied?
Title: MP3 repacker
Post by: Omion on 2007-03-19 17:44:22
mp3packer -z 8bp026-05-sabastian_boaz-cold_hard_fusion.mp3 (http://ftp://ftp.scene.org/pub/music/groups/8bitpeoples/8bp026-05-sabastian_boaz-cold_hard_fusion.mp3)
Quote
WARNING: error decompressing frame 57; copying frame data instead

How can the new file be without decompressing errors if the data is simply copied?

The new file will have the exact same decompression errors as the input file. mp3packer was not designed to fix errors, but rather to not create new ones. The reasoning behind this is simple: the best way to make the process lossless is to make sure that both files have the same errors. (mp3packer does fix sync errors, but that's only because it would be impossible to exactly recreate them)

I checked the file, and it seems to be a simple data overflow in the frame. The frame says it uses 42 bits, but it actually uses either 41 or 47. Most decoders just toss out the data from the end if this happens, but mp3packer keeps the bad data and lets the player deal with it (just like the original file)
Title: MP3 repacker
Post by: Martin F. on 2007-03-19 18:04:31
The new file will have the exact same decompression errors as the input file.
But why doesn’t MP3packer complain about them?

Code: [Select]
mp3packer -z 8bp026-05-sabastian_boaz-cold_hard_fusion.mp3

*** '8bp026-05-sabastian_boaz-cold_hard_fusion.mp3' -> '8bp026-05-sabastian_boaz-cold_hard_fusion-vbr.mp3'
WARNING: error decompressing frame 57; copying frame data instead
WARNING: error decompressing frame 69; copying frame data instead
WARNING: error decompressing frame 133; copying frame data instead
WARNING: recompressing frame 145 failed; copying frame data instead
WARNING: error decompressing frame 147; copying frame data instead
WARNING: error decompressing frame 210; copying frame data instead
WARNING: error decompressing frame 222; copying frame data instead
WARNING: recompressing frame 232 failed; copying frame data instead
WARNING: error decompressing frame 261; copying frame data instead
WARNING: error decompressing frame 279; copying frame data instead
WARNING: recompressing frame 290 failed; copying frame data instead
WARNING: error decompressing frame 299; copying frame data instead
WARNING: error decompressing frame 346; copying frame data instead
WARNING: error decompressing frame 357; copying frame data instead
WARNING: error decompressing frame 365; copying frame data instead
WARNING: error decompressing frame 366; copying frame data instead
WARNING: error decompressing frame 376; copying frame data instead
WARNING: error decompressing frame 395; copying frame data instead
WARNING: recompressing frame 470 failed; copying frame data instead
WARNING: error decompressing frame 623; copying frame data instead
WARNING: error decompressing frame 624; copying frame data instead
WARNING: error decompressing frame 652; copying frame data instead
WARNING: error decompressing frame 749; copying frame data instead
WARNING: error decompressing frame 750; copying frame data instead
WARNING: error decompressing frame 758; copying frame data instead
WARNING: error decompressing frame 815; copying frame data instead
WARNING: error decompressing frame 816; copying frame data instead
WARNING: error decompressing frame 824; copying frame data instead
WARNING: error decompressing frame 826; copying frame data instead
WARNING: error decompressing frame 845; copying frame data instead
WARNING: error decompressing frame 874; copying frame data instead
WARNING: error decompressing frame 891; copying frame data instead
WARNING: error decompressing frame 903; copying frame data instead
WARNING: recompressing frame 917 failed; copying frame data instead
WARNING: error decompressing frame 1083; copying frame data instead
WARNING: error decompressing frame 1125; copying frame data instead
WARNING: recompressing frame 1180 failed; copying frame data instead
WARNING: error decompressing frame 1222; copying frame data instead
WARNING: error decompressing frame 1236; copying frame data instead
WARNING: error decompressing frame 1259; copying frame data instead
WARNING: error decompressing frame 1264; copying frame data instead
WARNING: recompressing frame 1298 failed; copying frame data instead
WARNING: error decompressing frame 1303; copying frame data instead
WARNING: error decompressing frame 1437; copying frame data instead
WARNING: recompressing frame 1438 failed; copying frame data instead
WARNING: recompressing frame 1457 failed; copying frame data instead
WARNING: error decompressing frame 1486; copying frame data instead
WARNING: error decompressing frame 1504; copying frame data instead
WARNING: recompressing frame 1515 failed; copying frame data instead
WARNING: recompressing frame 1547 failed; copying frame data instead
WARNING: error decompressing frame 1571; copying frame data instead
WARNING: error decompressing frame 1590; copying frame data instead
WARNING: error decompressing frame 1591; copying frame data instead
WARNING: error decompressing frame 1601; copying frame data instead
WARNING: recompressing frame 1620 failed; copying frame data instead
WARNING: recompressing frame 1623 failed; copying frame data instead
WARNING: error decompressing frame 1624; copying frame data instead
WARNING: error decompressing frame 1690; copying frame data instead
WARNING: error decompressing frame 1695; copying frame data instead
WARNING: recompressing frame 1796 failed; copying frame data instead
WARNING: recompressing frame 1848 failed; copying frame data instead
WARNING: error decompressing frame 1853; copying frame data instead
WARNING: recompressing frame 1872 failed; copying frame data instead
WARNING: error decompressing frame 1877; copying frame data instead
WARNING: error decompressing frame 1896; copying frame data instead
WARNING: error decompressing frame 1974; copying frame data instead
WARNING: error decompressing frame 1983; copying frame data instead
WARNING: error decompressing frame 2040; copying frame data instead
WARNING: error decompressing frame 2041; copying frame data instead
WARNING: error decompressing frame 2049; copying frame data instead
WARNING: error decompressing frame 2051; copying frame data instead
WARNING: error decompressing frame 2070; copying frame data instead
WARNING: error decompressing frame 2099; copying frame data instead
WARNING: error decompressing frame 2104; copying frame data instead
WARNING: error decompressing frame 2116; copying frame data instead
WARNING: error decompressing frame 2128; copying frame data instead
WARNING: recompressing frame 2183 failed; copying frame data instead
WARNING: error decompressing frame 2202; copying frame data instead
WARNING: error decompressing frame 2204; copying frame data instead
WARNING: error decompressing frame 2213; copying frame data instead
WARNING: error decompressing frame 2233; copying frame data instead
WARNING: error decompressing frame 2308; copying frame data instead
WARNING: recompressing frame 2389 failed; copying frame data instead
WARNING: error decompressing frame 2405; copying frame data instead
WARNING: error decompressing frame 2407; copying frame data instead
WARNING: error decompressing frame 2409; copying frame data instead
WARNING: error decompressing frame 2430; copying frame data instead
WARNING: error decompressing frame 2444; copying frame data instead
WARNING: error decompressing frame 2461; copying frame data instead
WARNING: error decompressing frame 2489; copying frame data instead
WARNING: error decompressing frame 2525; copying frame data instead
WARNING: recompressing frame 2528 failed; copying frame data instead
WARNING: error decompressing frame 2654; copying frame data instead
WARNING: error decompressing frame 2662; copying frame data instead
WARNING: recompressing frame 2663 failed; copying frame data instead
WARNING: error decompressing frame 2695; copying frame data instead
WARNING: error decompressing frame 2714; copying frame data instead
WARNING: error decompressing frame 2715; copying frame data instead
WARNING: error decompressing frame 2729; copying frame data instead
WARNING: recompressing frame 2740 failed; copying frame data instead
WARNING: error decompressing frame 2796; copying frame data instead
WARNING: error decompressing frame 2807; copying frame data instead
WARNING: error decompressing frame 2815; copying frame data instead
WARNING: error decompressing frame 2826; copying frame data instead
WARNING: recompressing frame 2845 failed; copying frame data instead
WARNING: error decompressing frame 2863; copying frame data instead
WARNING: recompressing frame 2920 failed; copying frame data instead
WARNING: error decompressing frame 2997; copying frame data instead
WARNING: error decompressing frame 3073; copying frame data instead
WARNING: error decompressing frame 3074; copying frame data instead
WARNING: recompressing frame 3094 failed; copying frame data instead
WARNING: error decompressing frame 3102; copying frame data instead
WARNING: error decompressing frame 3132; copying frame data instead
WARNING: error decompressing frame 3141; copying frame data instead
WARNING: error decompressing frame 3199; copying frame data instead
WARNING: error decompressing frame 3200; copying frame data instead
WARNING: error decompressing frame 3208; copying frame data instead
WARNING: error decompressing frame 3266; copying frame data instead
WARNING: recompressing frame 3274 failed; copying frame data instead
WARNING: error decompressing frame 3276; copying frame data instead
WARNING: error decompressing frame 3295; copying frame data instead
WARNING: recompressing frame 3341 failed; copying frame data instead
WARNING: error decompressing frame 3353; copying frame data instead
WARNING: error decompressing frame 3361; copying frame data instead
WARNING: error decompressing frame 3400; copying frame data instead
WARNING: error decompressing frame 3408; copying frame data instead
WARNING: error decompressing frame 3427; copying frame data instead
WARNING: error decompressing frame 3429; copying frame data instead
WARNING: recompressing frame 3438 failed; copying frame data instead
WARNING: error decompressing frame 3458; copying frame data instead
WARNING: error decompressing frame 3533; copying frame data instead
WARNING: recompressing frame 3630 failed; copying frame data instead
WARNING: error decompressing frame 3658; copying frame data instead
WARNING: error decompressing frame 3686; copying frame data instead
WARNING: recompressing frame 3714 failed; copying frame data instead
WARNING: error decompressing frame 3724; copying frame data instead
WARNING: error decompressing frame 3753; copying frame data instead
WARNING: error decompressing frame 3811; copying frame data instead
WARNING: error decompressing frame 3820; copying frame data instead
WARNING: error decompressing frame 3879; copying frame data instead
WARNING: error decompressing frame 3887; copying frame data instead
WARNING: recompressing frame 3888 failed; copying frame data instead
WARNING: recompressing frame 3907 failed; copying frame data instead
WARNING: error decompressing frame 3936; copying frame data instead
WARNING: error decompressing frame 3941; copying frame data instead
WARNING: error decompressing frame 3954; copying frame data instead
WARNING: recompressing frame 3965 failed; copying frame data instead
WARNING: error decompressing frame 4021; copying frame data instead
WARNING: error decompressing frame 4040; copying frame data instead
WARNING: error decompressing frame 4041; copying frame data instead
WARNING: error decompressing frame 4051; copying frame data instead
WARNING: recompressing frame 4070 failed; copying frame data instead
WARNING: recompressing frame 4145 failed; copying frame data instead
WARNING: error decompressing frame 4298; copying frame data instead
WARNING: error decompressing frame 4299; copying frame data instead
WARNING: error decompressing frame 4327; copying frame data instead
WARNING: error decompressing frame 4425; copying frame data instead
WARNING: error decompressing frame 4491; copying frame data instead
WARNING: recompressing frame 4499 failed; copying frame data instead
WARNING: error decompressing frame 4501; copying frame data instead
WARNING: error decompressing frame 4520; copying frame data instead
WARNING: error decompressing frame 4549; copying frame data instead
WARNING: error decompressing frame 4566; copying frame data instead
WARNING: error decompressing frame 4578; copying frame data instead
WARNING: error decompressing frame 4586; copying frame data instead
WARNING: recompressing frame 4633 failed; copying frame data instead
WARNING: recompressing frame 4652 failed; copying frame data instead
WARNING: error decompressing frame 4654; copying frame data instead
WARNING: recompressing frame 4663 failed; copying frame data instead
WARNING: error decompressing frame 4683; copying frame data instead
WARNING: error decompressing frame 4758; copying frame data instead
WARNING: recompressing frame 4855 failed; copying frame data instead
WARNING: error decompressing frame 4883; copying frame data instead
WARNING: error decompressing frame 4957; copying frame data instead
WARNING: error decompressing frame 4969; copying frame data instead
WARNING: error decompressing frame 5033; copying frame data instead
WARNING: recompressing frame 5045 failed; copying frame data instead
WARNING: error decompressing frame 5047; copying frame data instead
WARNING: error decompressing frame 5064; copying frame data instead
WARNING: error decompressing frame 5072; copying frame data instead
WARNING: recompressing frame 5084 failed; copying frame data instead
WARNING: error decompressing frame 5122; copying frame data instead
100% done with 5208 frames

On this new file MP3packer only reports the recompression errors:

Code: [Select]
mp3packer -z 8bp026-05-sabastian_boaz-cold_hard_fusion-vbr.mp3

*** '8bp026-05-sabastian_boaz-cold_hard_fusion-vbr.mp3' -> '8bp026-05-sabastian_boaz-cold_hard_fusion-vbr-vbr.mp3'
WARNING: recompressing frame 145 failed; copying frame data instead
WARNING: recompressing frame 232 failed; copying frame data instead
WARNING: recompressing frame 290 failed; copying frame data instead
WARNING: recompressing frame 470 failed; copying frame data instead
WARNING: recompressing frame 917 failed; copying frame data instead
WARNING: recompressing frame 1180 failed; copying frame data instead
WARNING: recompressing frame 1298 failed; copying frame data instead
WARNING: recompressing frame 1438 failed; copying frame data instead
WARNING: recompressing frame 1457 failed; copying frame data instead
WARNING: recompressing frame 1515 failed; copying frame data instead
WARNING: recompressing frame 1547 failed; copying frame data instead
WARNING: recompressing frame 1620 failed; copying frame data instead
WARNING: recompressing frame 1623 failed; copying frame data instead
WARNING: recompressing frame 1796 failed; copying frame data instead
WARNING: recompressing frame 1848 failed; copying frame data instead
WARNING: recompressing frame 1872 failed; copying frame data instead
WARNING: recompressing frame 2183 failed; copying frame data instead
WARNING: recompressing frame 2389 failed; copying frame data instead
WARNING: recompressing frame 2528 failed; copying frame data instead
WARNING: recompressing frame 2663 failed; copying frame data instead
WARNING: recompressing frame 2740 failed; copying frame data instead
WARNING: recompressing frame 2845 failed; copying frame data instead
WARNING: recompressing frame 2920 failed; copying frame data instead
WARNING: recompressing frame 3094 failed; copying frame data instead
WARNING: recompressing frame 3274 failed; copying frame data instead
WARNING: recompressing frame 3341 failed; copying frame data instead
WARNING: recompressing frame 3438 failed; copying frame data instead
WARNING: recompressing frame 3630 failed; copying frame data instead
WARNING: recompressing frame 3714 failed; copying frame data instead
WARNING: recompressing frame 3888 failed; copying frame data instead
WARNING: recompressing frame 3907 failed; copying frame data instead
WARNING: recompressing frame 3965 failed; copying frame data instead
WARNING: recompressing frame 4070 failed; copying frame data instead
WARNING: recompressing frame 4145 failed; copying frame data instead
WARNING: recompressing frame 4499 failed; copying frame data instead
WARNING: recompressing frame 4633 failed; copying frame data instead
WARNING: recompressing frame 4652 failed; copying frame data instead
WARNING: recompressing frame 4663 failed; copying frame data instead
WARNING: recompressing frame 4855 failed; copying frame data instead
WARNING: recompressing frame 5045 failed; copying frame data instead
WARNING: recompressing frame 5084 failed; copying frame data instead
100% done with 5208 frames
Title: MP3 repacker
Post by: j7n on 2007-03-22 06:43:46
Mp3Packer does not preserve gapless information from an "Info" frame (Xing frame in constant bitrate files).
Title: MP3 repacker
Post by: Omion on 2007-03-22 07:03:34
Mp3Packer does not preserve gapless information from an "Info" frame (Xing frame in constant bitrate files).

I've had no problems with it. I just did a quick CBR128 encode, which registers in Foobar as having the same sample offsets. Which LAME version are you using? Somebody may have screwed up the spec when I wasn't looking. (and an example file would be helpful too)

@Martin F.
Sorry for the delay. I got sick last week and haven't gotten up the energy to do much debugging. However, what you are describing does sound like a bug (as I said, the same errors should be in both files) I'll look into it as soon as the flu gives me the chance to. In the meantime, I'm going to bed
Title: MP3 repacker
Post by: j7n on 2007-03-22 07:16:16
I manully added the gappless information using Foobar 0.9.4.1. I just checked that it didn't create the complete frame, only number of frames, filelength and gapless data. This was the problem, complete Info frames added by Foobar 0.8.3 were preserved.

However, VBR frames containing only the most important information were also created by earlier versions of Mp3DirectCut, and shouldn't be ignored. There is no way Foobar 9 will reindex an mp3 file it detects it as CBR.
Title: MP3 repacker
Post by: Omion on 2007-03-23 06:12:06
I manully added the gappless information using Foobar 0.9.4.1. I just checked that it didn't create the complete frame, only number of frames, filelength and gapless data. This was the problem, complete Info frames added by Foobar 0.8.3 were preserved.

However, VBR frames containing only the most important information were also created by earlier versions of Mp3DirectCut, and shouldn't be ignored. There is no way Foobar 9 will reindex an mp3 file it detects it as CBR.

I see the problem now. It's Foobar's fault. 

It looks like Foobar still makes LAME tags without bothering to set the CRC. I already worked around this problem once in 1.07, and I don't want to bend the spec any more than I already have.
The CRC info at the end of a LAME tag is by far the best way of determining whether or not it's a LAME tag or just an XING tag with random garbage at the end. Bad CRC = no LAME tag.

The only exception I made to this was if all the extra LAME info was 0 except for the padding, it would still register as a LAME tag. This was specifically to work around Foobar not updating the frame correctly. However, it looks like now Foobar is smart enough to fill in some other info, but still can't get the CRC right.

In a nutshell, I won't fix this problem, simply because it is not mine to fix. The best way to get it fixed would be to post the issue in Foobar's support forum. The only other reference to the issue is in this post (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=35654&view=findpost&p=314897), so it's possible that the Foobar guys don't know about it yet.
Title: MP3 repacker
Post by: Omion on 2007-03-23 06:42:58
@Martin F.:

I see the problem now. mp3packer says it keeps the input data on those frames, but in fact it still uses the recompressed data

It actually took me a bit of time trying to find the problem, since I had already fixed it in my working copy of mp3packer  . There is a certain type of bitstream error that is fairly common and all MP3 players seem to deal with it the same. In all the release versions this type of error was fixed nicely, but a warning came up saying the error was not fixed... The next version will simply fix the error and go on repacking.


(I know I'm kind of contradicting myself here: I said before that mp3packer will faithfully reproduce the input errors, but now I'm saying that it will fix those errors. However, the errors that I am fixing here are a small subclass of errors; they are extremely minor, relatively common, and all players deal with them the same. In these cases I think it is wise to simply fix the error, as playback will still be exactly the same.)
Title: MP3 repacker
Post by: j7n on 2007-03-25 02:56:44
Quote
The best way to get it fixed would be to post the issue in Foobar's support forum. The only other reference to the issue is in this post (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=35654&view=findpost&p=314897), so it's possible that the Foobar guys don't know about it yet.

Done (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=50434&view=findpost&p=480794). But I'm afraid that post will gonna get ignored, since it says between the lines that Fb 0.8 did something better than 0.9 does.
Title: MP3 repacker
Post by: Martin F. on 2007-03-30 16:05:48
Thanks for your reply, Omion. Interesting insights in some details of the MP3 format.

So here’s my next question  I noticed mp3packer -z is very fast on some files, for example on this (http://freesound.iua.upf.edu/samplesViewSingle.php?id=17085) (cough) (http://www.bugmenot.com/view/freesound.iua.upf.edu) 34 MB sized file (faster than on a usual file one tenth in size). The files on which I noticed this exceptional speed have a sampling rate of 22050 Hz in common. I don’t know why the sampling rate could have an effect on the compression speed, and the sampling rate and the speed may have no correlation at all  but it’s the only unusual attribute I could find on these files. Do you have an explanation for this?


// Edit: I’m having trouble using mp3packer on Windows 98 with a large file (2.12 GB):

Code: [Select]
D:\Martin>dir
[…]
FFN-CH~1 MP3 2.278.070.131  01.07.06  23:46 ffn-charts.mp3
MP3PAC~1 EXE       647.168  18.02.07  19:13 mp3packer.exe
[…]
         2 Datei(en)         2.278.717.299 Bytes
         4 Verzeichnis(se)       11.211,95 MB frei

D:\Martin>mp3packer -z ffn-charts.mp3
Fatal error: exception Failure("'ffn-charts.mp3' does not exist")

D:\Martin>mp3packer -z ffn-ch~1.mp3
Fatal error: exception Failure("'ffn-ch~1.mp3' does not exist")
Title: MP3 repacker
Post by: j7n on 2007-03-30 18:58:05
I have a question about the bit reservoir

I was under impression that if I repack a medium bitrate stream with -b 320 parameter, the bit reservoir won't be used for most frames in the stream. I needed to edit a live recording @ 192 kBit/s and followed this path. The output stream contained lots of nulls, but still I was unable to cut the stream without glitches.

How is bit reservoir treated when repackaging mp3 data?
Title: MP3 repacker
Post by: Omion on 2007-03-31 01:11:37
Thanks for your reply, Omion. Interesting insights in some details of the MP3 format.

So here’s my next question  I noticed mp3packer -z is very fast on some files, for example on this (http://freesound.iua.upf.edu/samplesViewSingle.php?id=17085) (cough) (http://www.bugmenot.com/view/freesound.iua.upf.edu) 34 MB sized file (faster than on a usual file one tenth in size). The files on which I noticed this exceptional speed have a sampling rate of 22050 Hz in common. I don’t know why the sampling rate could have an effect on the compression speed, and the sampling rate and the speed may have no correlation at all  but it’s the only unusual attribute I could find on these files. Do you have an explanation for this?

Actually, I seem to remember something about not enabling the -z switch with MPEG2 files (which are what files < 32KHz are) I don't remember why, but I'll see what happens when I re-enable it. I'm at work right now  so I can't do much here, but I'll test it out when I get home.

Quote
// Edit: I’m having trouble using mp3packer on Windows 98 with a large file (2.12 GB):

Code: [Select]
D:\Martin>dir
[…]
FFN-CH~1 MP3 2.278.070.131  01.07.06  23:46 ffn-charts.mp3
MP3PAC~1 EXE       647.168  18.02.07  19:13 mp3packer.exe
[…]
         2 Datei(en)         2.278.717.299 Bytes
         4 Verzeichnis(se)       11.211,95 MB frei

D:\Martin>mp3packer -z ffn-charts.mp3
Fatal error: exception Failure("'ffn-charts.mp3' does not exist")

D:\Martin>mp3packer -z ffn-ch~1.mp3
Fatal error: exception Failure("'ffn-ch~1.mp3' does not exist")

Accessing files larger than 2GB in Win 9x is not straightforward. I don't think OCaml can do it...


I have a question about the bit reservoir

I was under impression that if I repack a medium bitrate stream with -b 320 parameter, the bit reservoir won't be used for most frames in the stream. I needed to edit a live recording @ 192 kBit/s and followed this path. The output stream contained lots of nulls, but still I was unable to cut the stream without glitches.

How is bit reservoir treated when repackaging mp3 data?


Actually, the way it works is that almost every frame will use the entire bit reservoir. Since almost no frames  use all that space, the next frame will use up as much of the reservoir as possible. What that means is that using "-b 320" will actually lose the most data at the split point.

I have been thinking about trying to minimize the bit reservoir if the program determines that it won't take up any space, but when not using the "-b" switch this will need to cache very large chunks of the file. I'll see if there's a reasonable middle-ground to this.

What I would do to properly cut mp3 files is use pcutmp3 (http://www.hydrogenaudio.org/forums/index.php?showtopic=35654), which is designed to avoid any errors. If whatever you use to play them back doesn't support LAME tags, then it won't quite be gapless, but it's as close as mp3s can get.
Title: MP3 repacker
Post by: Jojo on 2007-04-30 04:39:49
I'm assuming that the program's output is lossless? I'm partially wondering about the -z switch. Is it lossless as well?

thanks
Title: MP3 repacker
Post by: gib on 2007-04-30 05:19:28
It is lossless, with or without the -z switch.  Obviously, if you have any concerns, you could always do a foobar bit-compare to verify the packed mp3 is lossless before tossing the original.  I do that, but then I tend to be a bit overly cautious.  heh
Title: MP3 repacker
Post by: nemoW on 2007-05-01 18:32:31
Why MP3Packer (I use WinMP3Packer 1.13) rewrite 'encoder' field (http://images.people.overclockers.ru/121051.png) in mp3 files?
Title: MP3 repacker
Post by: Omion on 2007-05-01 19:14:42
Why MP3Packer (I use WinMP3Packer 1.13) rewrite 'encoder' field (http://images.people.overclockers.ru/121051.png) in mp3 files?

I did a little test with Tag&Rename, and it looks like it will guess the encoder if it is not available in a field anywhere.

LAME will put its version data in the padding info (you have to put something in the padding, so it might as well be useful) If Tag&Rename doesn't see any actual encoder field, it will use this padding data as the encoder.
That's great, except that the padding is exactly what mp3packer gets rid of! So when you put the files through mp3packer, that prevents Tag&Rename from guessing correctly.

So really, it's not rewriting the encoder field, but it is rewriting a hint that Tag&Rename uses to guess at the encoder. If the file stores the encoder data in the tags or in a LAME/XING frame, mp3packer will save it to the output file.



It is odd, though. When mp3packer can't find an encoder field, it will write its own name as the encoder (the header that mp3packer uses requires it) but it looks like Tag&Rename doesn't recognize this; it just assumes Xing for everything...
Title: MP3 repacker
Post by: nemoW on 2007-05-01 22:05:58
I did a little test with Tag&Rename, and it looks like it will guess the encoder if it is not available in a field anywhere.

I am not familiar with mp3 file structure, but it seems like original files (from my 1st post) doesn't have LAME/XING header (here first bytes of file (http://images.people.overclockers.ru/121063.png)).

Quote
If the file stores the encoder data in the tags or in a LAME/XING frame, mp3packer will save it to the output file.

It is odd, though. When mp3packer can't find an encoder field, it will write its own name as the encoder (the header that mp3packer uses requires it) but it looks like Tag&Rename doesn't recognize this; it just assumes Xing for everything...
Hmm...

I've made aditional tests. Algorthm:
1. Encode small wav file with Lame 3.96.1 to cbr & vbr;
2. Convert with mp3packer cbr>vbr & vbr>cbr;
3. Convert again vbr>cbr & cbr>vbr;
Here (http://images.people.overclockers.ru/121072.png) interesting results.
Title: MP3 repacker
Post by: Omion on 2007-05-01 22:42:49
I am not familiar with mp3 file structure, but it seems like original files (from my 1st post) doesn't have LAME/XING header (here first bytes of file (http://images.people.overclockers.ru/121063.png)).

Yeah. That file just goes right into the MP3 data. No headers whatsoever.

Quote
Hmm...

I've made aditional tests. Algorthm:
1. Encode small wav file with Lame 3.96.1 to cbr & vbr;
2. Convert with mp3packer cbr>vbr & vbr>cbr;
3. Convert again vbr>cbr & cbr>vbr;
Here (http://images.people.overclockers.ru/121072.png) interesting results.

mp3packer uses a slightly different header for CBR and VBR files, although they are functionally the same. It looks like that program is picking up the encoder from the VBR header, but not from the CBR header. But this doesn't explain why the VBR header isn't recognized in the files you mentioned on your first post, though...
Title: MP3 repacker
Post by: buktore on 2007-05-03 15:18:40
I found something interrest. if i convert VBR > CBR > VBR

you got converted VBR file that (a bit)smaller than the original VBR.

maybe you can add an option to "squeeze VBR file" option or something.
Title: MP3 repacker
Post by: Omion on 2007-05-03 15:58:08
I found something interrest. if i convert VBR > CBR > VBR

you got converted VBR file that (a bit)smaller than the original VBR.

maybe you can add an option to "squeeze VBR file" option or something.

You may notice that converting VBR > VBR gives the same improvement. The command line will take any MP3 file and repack it to a VBR by default. It looks like with the GUI you have to set "Input Types" to "All" to do the same thing.

How much smaller is the output file, though? It's rare to be able to compress it more than a couple hundred bytes without using the "-z" switch.
Title: MP3 repacker
Post by: buktore on 2007-05-03 17:19:51
Ah.. you are right. VBR > VBR  give the same file as VBR > CBR > VBR. Silly me.

and yeah. it get only tiny bit smaller. but i remember i once see that it's smaller enough to not show 0.0% (but how much.. i can't remember)

and thanks for this great tool  i love it.

PS.sorry if my ENG is bad
Title: MP3 repacker
Post by: Omion on 2007-05-10 06:50:17
1.16 is out! (http://omion.dyndns.org/mp3packer/mp3packer-1.16.rar) Huzzah!

I basically completely re-wrote the entire thing, which is why it took almost three months. I did fairly extensive regression testing, but there may still have been bugs that slipped through. You are strongly encouraged to check the files before deleting the originals!

Here's what changed:Also, along the way, I noticed and fixed the following issues:The -r and -R switches are interesting. mp3packer used to try to minimize frame size, then maximize bit reservoir usage in the frame. This is exactly what you need to make the file as small as possible, but it had a tendency to peg the reservoir when the -b switch was used. I address this issue at the bottom of this post (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=32379&view=findpost&p=482143). mp3packer will now figure out the minimum bit reservoir for a frame to use without screwing up the bitrate of any frames after it. However, if the -b switch is not used the analysis may take a lot of memory, and probably won't do anything at all. Therefore, the bit reservoir is only minimized if the -b switch is given. Otherwise it is maximized like before.

The -r switch makes it so that the bitrate reservoir is always minimized, whereas the -R switch will maximize the reservoir (the normal operation for mp3packer before 1.16)

Whew! Done at last!
Title: MP3 repacker
Post by: Martin F. on 2007-05-10 19:34:38
foo_bitcompare says

Comparing:
csr064_full-load-of-king_elevator-to-the-gallows_5_envelope-infrared_part-1.mp3 (http://ftp://ia300137.us.archive.org/1/items/csr064/csr064_full-load-of-king_elevator-to-the-gallows_5_envelope-infrared_part-1.mp3)
csr064_full-load-of-king_elevator-to-the-gallows_5_envelope-infrared_part-1-vbr.mp3
Comparing failed (length mismatch).

Comparing:
csr064_full-load-of-king_elevator-to-the-gallows_7_envelope-infrared_part-3.mp3 (http://ftp://ia300137.us.archive.org/1/items/csr064/csr064_full-load-of-king_elevator-to-the-gallows_7_envelope-infrared_part-3.mp3)
csr064_full-load-of-king_elevator-to-the-gallows_7_envelope-infrared_part-3-vbr.mp3
differences found: 3132 sample(s), starting at 71.0415193 second(s), peak: 0.0008336 at 71.0554422 second(s), 1ch

Also happened with the previous version (that reported lots of re- and/or decompression errors). I’ve used the -z switch.

Taken from csr064 (http://www.archive.org/details/csr064), author: Full Load of King (http://www.archive.org/search.php?query=creator:%22Full%20Load%20of%20King%22), CC licensed (http://creativecommons.org/licenses/by-nc/2.5/)
Title: MP3 repacker
Post by: Omion on 2007-05-12 03:40:30
@Martin:

Well, part 1 looks OK with 1.16. I've noticed that in Foobar sometimes you have to force a reload in order for the length to be updated.

Part 3 is indeed doing something odd. I'm trying to figure it out now...
Title: MP3 repacker
Post by: Martin F. on 2007-05-12 11:11:54
foobar2000 says

Quote
csr064_full-load-of-king_elevator-to-the-gallows_5_envelope-infrared_part-1.mp3
Duration : 4:02.770 (10706159 samples)

csr064_full-load-of-king_elevator-to-the-gallows_5_envelope-infrared_part-1-vbr.mp3
Duration : 4:02.796 (10707311 samples)


A reload doesn’t change it. I opened it in Cool Edit 2000 and it shows an additional (short) silent part at the beginning of the VBR file.
Title: MP3 repacker
Post by: Omion on 2007-05-24 06:43:59
1.17 is out.

I completely remade the -z switch with the hopes of it getting twice as fast and slightly higher compression. That didn't happen. Instead, I got a -z switch which is 40% slower and slightly higher compression. Most of the time I spent went toward optimizing it (before optimization it went 3x slower  ) Oh well. The -z switch was never meant to be fast. 

The compression improvement (and speed decrease) is mainly evident in low-bitrate encodes. For high bitrates I noticed a whopping 0.03% improvement in the file size versus 1.16.

I also fixed a few bugs related to the -i switch. I hadn't tested it out properly when I released 1.16, so it printed a bunch of garbage and got one of the results wrong. This didn't affect the repacking at all, though.
Title: MP3 repacker
Post by: 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?
Title: MP3 repacker
Post by: gottkaiser on 2007-05-25 01:54:37
@Omion

Thanks for developing this great tool!

Could you add a option to keep the time stamps of the old mp3 files?
Title: MP3 repacker
Post by: Omion on 2007-05-25 05:19:14
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.

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?
Title: MP3 repacker
Post by: gottkaiser on 2007-05-25 10:13:48
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!  :-)
Title: MP3 repacker
Post by: Polar on 2007-05-25 11:42:41
@Omion

Thanks for developing this great tool!
I can only second that.  Wiki article anyone?
Title: MP3 repacker
Post by: j7n on 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.).
Title: MP3 repacker
Post by: gottkaiser on 2007-05-25 19:35:03
@Omion

I created a Wiki article (http://wiki.hydrogenaudio.org/index.php?title=MP3packer). Maybe you can check it that it's ok like that.
Title: MP3 repacker
Post by: decayed.cell on 2007-05-26 09:03:16
Would it be possible to add Unicode filename support?
Title: MP3 repacker
Post by: Omion on 2007-05-27 02:07:55
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...
Title: MP3 repacker
Post by: j7n on 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.
Title: MP3 repacker
Post by: Omion on 2007-05-28 01:32:45
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  )
Title: MP3 repacker
Post by: j7n on 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.
Title: MP3 repacker
Post by: Ojay on 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")
Title: MP3 repacker
Post by: Omion on 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 (http://omion.dyndns.org/mp3packer/mp3reader-20070530.rar) 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!
Title: MP3 repacker
Post by: nemoW on 2007-05-31 20:46:04
Could MP3 repacker process MPEG-1 layer 2 files?
Title: MP3 repacker
Post by: Omion on 2007-06-01 05:00:39
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.
Title: MP3 repacker
Post by: 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?
Title: MP3 repacker
Post by: 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
Title: MP3 repacker
Post by: j7n on 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.)
Title: MP3 repacker
Post by: 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.

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.
Title: MP3 repacker
Post by: Polar on 2007-06-01 15:01:35
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
Title: MP3 repacker
Post by: radorn on 2007-06-01 15:22:38
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.
Title: MP3 repacker
Post by: Architectonical on 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 (http://www.archive.org/download/xgn014_-_salamandra/b-salamandra_-_unknown_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?

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.
Title: MP3 repacker
Post by: Jojo on 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.
Title: MP3 repacker
Post by: gib on 2007-06-02 00:50:47
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.
Title: MP3 repacker
Post by: radorn on 2007-06-02 01:32:18

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)
Title: MP3 repacker
Post by: Omion on 2007-06-02 05:23:41
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 (http://omion.dyndns.org/mp3packer/).

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:Note, again, that all of these issues are due to incorrectly-formed input files.


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?
Title: MP3 repacker
Post by: nemoW on 2007-06-02 14:26:27
In my tests any files coded with Lame show slight compression even with -z (~4% maximum for some 320CBR). But some high-bitrate CBR files encoded with other tools (iTunes etc.) can be compressed much better (up to 13% (http://images.people.overclockers.ru/124589.png)).
Title: MP3 repacker
Post by: Jojo on 2007-06-02 23:49:07
@Jojo:
What program are you using to identify the file? Was this the input or the output file that you checked?

to identify what tags a file contains I use mp3Tag, which I also used for tagging the file.
in terms of identifying what codec has been used I use Audio Identifier and double checked with foobar.
Title: MP3 repacker
Post by: gib on 2007-06-03 04:11:04
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.
Wow, thanks for the snarky response.  Not only is it unnecessary, but it also makes you sound like a complete jerk since you aren't even in the right.  I read your posts, and saying, "...check that the decoded sound is identical to the original..." does not imply you used foobar2000 to bit-compare the files - it implies you listened to the files, because that's what you do with sound.

In the future it's a good policy not to be pissy to someone who took a moment of time to post a possibly useful reply.  This is especially true when the initial failure is on your end due to not being clear in your posts.
Title: MP3 repacker
Post by: radorn on 2007-06-03 23:56:02
Thanks Omion, that mostly solves my doubts.

Also, I apologize for littering your program's thread.
I already moved the discussion with that "gib" guy to the private domain.

[...] saying "...check that the decoded sound is identical to the original..." does not imply you used foobar2000 to bit-compare the files - it implies you listened to the files, because that's what you do with sound.

In the future it's a good policy not to be pissy to someone who took a moment of time to post a possibly useful reply.  This is especially true when the initial failure is on your end due to not being clear in your posts.


Whatever, man.

I'll reply to your nonsense privatelly, because we have littered this thread enough so far.
Title: MP3 repacker
Post by: Omion on 2007-06-06 01:35:28
1.18 (http://omion.dyndns.org/mp3packer/mp3packer-1.18.rar) is out.

The main difference is the addition of the --nice switch. Use it to change mp3packer's priority.

The --nice switch has a similar range as the Unix "nice" utility. 0 is normal, 19 is idle, and negative numbers are higher priority. The exact mapping from Unix-range numbers to Windows priorities is listed in the mp3packer HTML file (http://omion.dyndns.org/mp3packer/mp3packer.html).

mp3packer will default to "--nice 10" which will show up as "below normal" in the task manager.

I also fixed some bugs which may or may not have existed.
Title: MP3 repacker
Post by: Polar on 2007-06-06 09:49:50
It's refreshing to see this tool being developed so actively, with updates and bug fixes issued at such short intervals.

That said, what about running MP3packer over freeformat (http://www.hydrogenaudio.org/forums/index.php?showtopic=38808) MP3s encoded at, say, 325 kbps?  I was wondering: if you're lucky enough to squeeze out enough bits to get them down to 320 kbps (that's just 1.5%, so using the -z switch you should, right?), could this be a nice 'n' clean way to get the highest possible encoding quality for 16 bit stereo MP3s, without breaking compatibility with just about any MP3 software or hardware on the planet?

I have little to no experience with freeformat MP3 files, so it may very well be that I'm daydreaming here.  So if I am, sorry in advance.

Evidently, anyone being that pedantic about audio quality willing to go through the fuss of encoding to freeformat 325 kbps in stead of plain standard CBR 320 kbps, (edit:) without any ABXable improvements, should be referred to any lossless codec of choice.  So my question is purely from a point of view of interest in the format, and in MP3packer.  After all, MP3 having the pile driver ascendancy over any other format it has, for the marginal audience looking for maximum compatibility along with maximum encoding quality, IMHO, this exercise might prove to be worth a small second of attention.


couldn't this funktion be put into lame ? some thing like -repack
Any news on this?  Worth contacting the LAME developers, if not done so already?
Title: MP3 repacker
Post by: Omion on 2007-06-06 19:57:07
It's refreshing to see this tool being developed so actively, with updates and bug fixes issued at such short intervals.

That said, what about running MP3packer over freeformat (http://www.hydrogenaudio.org/forums/index.php?showtopic=38808) MP3s encoded at, say, 325 kbps?  I was wondering: if you're lucky enough to squeeze out enough bits to get them down to 320 kbps (that's just 1.5%, so using the -z switch you should, right?), could this be a nice 'n' clean way to get the highest possible encoding quality for 16 bit stereo MP3s, without breaking compatibility with just about any MP3 software or hardware on the planet?

I have little to no experience with freeformat MP3 files, so it may very well be that I'm daydreaming here.  So if I am, sorry in advance.

Evidently, anyone being that pedantic about audio quality willing to go through the fuss of encoding to freeformat 325 kbps in stead of plain standard CBR 320 kbps, (edit:) without any ABXable improvements, should be referred to any lossless codec of choice.  So my question is purely from a point of view of interest in the format, and in MP3packer.  After all, MP3 having the pile driver ascendancy over any other format it has, for the marginal audience looking for maximum compatibility along with maximum encoding quality, IMHO, this exercise might prove to be worth a small second of attention.


It would be possible to make it accept freeformat MP3s, and I looked into it a while ago. The problem is that I don't think anybody uses freeformat at 325kbps (do they?  ), and the possibility of turning freeformat into something useful decreases rapidly above 320kbps.

I had wanted to support converting from allofmp3's 384kbps to 320kbps, since I figured that would be the most popular source of freeformat files. However, in the tests that I did, there were simply too many bits to cram into 320kbps.

I made a program a while ago which can tell the smallest frame size required for a freeformat stream, assuming that the bit reservoir can be used. Run this program (http://omion.dyndns.org/mp3packer/limitedformat_check.rar) on a freeformat mp3 and it will tell you the minimum frame size needed to store all the bits. For 44.1KHz files, if this number is larger than 1009 then the file must be freeformat.

Quote
couldn't this funktion be put into lame ? some thing like -repack
Any news on this?  Worth contacting the LAME developers, if not done so already?

I don't think it's worth putting into LAME. LAME mp3 files don't get much benefit from repacking, and if you want to convert to CBR, why not call LAME with CBR options...

The -z switch is somewhat useful, but the code required for it is fairly big. Plus, it's all written in OCaml, which is somewhat difficult to integrate into C programs.

All in all, I don't see much benefit from combining mp3packer with any encoders.
Title: MP3 repacker
Post by: Polar on 2007-06-07 09:29:58
It would be possible to make it accept freeformat MP3s, and I looked into it a while ago. The problem is that I don't think anybody uses freeformat at 325kbps (do they?  ) ...
Not yet

... and the possibility of turning freeformat into something useful decreases rapidly above 320kbps.

I had wanted to support converting from allofmp3's 384kbps to 320kbps, since I figured that would be the most popular source of freeformat files. However, in the tests that I did, there were simply too many bits to cram into 320kbps.
So if I get it right, that means MP3packer currently doesn't support freeformat at all?  I'll agree that it would be of very marginal use anyway.

I don't think it's worth putting into LAME. LAME mp3 files don't get much benefit from repacking, and if you want to convert to CBR, why not call LAME with CBR options...
Imho, having LAME offer the opportunity to repack any high-bitrate CBR encode out-of-the-box, especially --preset insane, could have its use though.

Edit: fixed quotes.
Title: MP3 repacker
Post by: nemoW on 2007-06-07 19:21:55
All in all, I don't see much benefit from combining mp3packer with any encoders.

It is known, that mp3 cannot be compressed with any archivers. Only SoundSlimmer (http://www.soundslimmer.com/) can losslessly compress (not repack!) mp3 - partially decode/unpack mp3 and compress unpacked stream with more strong algorithm than mp3 use. But SoundSlimmer is shareware, cmd version absent, no winamp plug-in etc.
Quote
-z
This option makes mp3packer partially decode the audio in the file, optimize the data, then recode it.

Adjacent question: could mp3packer produce partially decoded output (neither mp3, nor wav) that might be compressed with general purpose archivers (and losslessly reverted to mp3)?

Excuse for my bad English.
Title: MP3 repacker
Post by: Omion on 2007-06-08 07:49:31
So if I get it right, that means MP3packer currently doesn't support freeformat at all?  I'll agree that it would be of very marginal use anyway.

Right. A freeformat mp3 will pass straight through mp3packer as though it were invalid.

Quote
Imho, having LAME offer the opportunity to repack any high-bitrate CBR encode out-of-the-box, especially --preset insane, could have its use though.

That would make sense, but I don't really think it'd help. I have the feeling that many people who use --preset insane are using it because it is "the highest quality that mp3 can go". If they ended up with a VBR 312kbps file, they'd complain that it was not maxing out the potential of the mp3 file format. Some people would understand it, but they could download the standalone program if they needed. 

Adjacent question: could mp3packer produce partially decoded output (neither mp3, nor wav) that might be compressed with general purpose archivers (and losslessly reverted to mp3)?

It's unlikely that a general-purpose archiver would be able to do better with raw, decoded mp3 data than mp3 itself. However, I'll keep it in mind and make a test when I'm less busy.
Title: MP3 repacker
Post by: Firon on 2007-06-08 07:57:25

Adjacent question: could mp3packer produce partially decoded output (neither mp3, nor wav) that might be compressed with general purpose archivers (and losslessly reverted to mp3)?

It's unlikely that a general-purpose archiver would be able to do better with raw, decoded mp3 data than mp3 itself. However, I'll keep it in mind and make a test when I'm less busy.


Using arithmetic coding instead of huffman would probably improve the compression ratio noticeably.
Title: MP3 repacker
Post by: smack on 2007-06-08 09:35:05



Adjacent question: could mp3packer produce partially decoded output (neither mp3, nor wav) that might be compressed with general purpose archivers (and losslessly reverted to mp3)?

It's unlikely that a general-purpose archiver would be able to do better with raw, decoded mp3 data than mp3 itself. However, I'll keep it in mind and make a test when I'm less busy.


Using arithmetic coding instead of huffman would probably improve the compression ratio noticeably.

@Firon
It's true that arithmetic coding is more efficient than Huffman coding so it wouldn't hurt to test it for mp3 repacking. However, the more significant improvements in compression ratio usually come from a better "understanding" of the data to be compressed in order to apply special algorithms for certain types of data. (context modeling / context mixing, see also: Wikipedia: PAQ (http://en.wikipedia.org/wiki/PAQ))

@Omion
It should be possible to losslessly compress mp3 better using a more sophisticated algorithm. For comparison just look at the results of the Lossless JPEG compression test (http://www.maximumcompression.com/data/jpg.php).

Rather than implementing de-packing in mp3packer and using another program (for instance a general-purpose archiver) to compress the de-packed mp3, IMO it would be more useful to implement a new context model for mp3 data in an existing program like PAQ (http://www.cs.fit.edu/~mmahoney/compression/).
Title: MP3 repacker
Post by: j7n on 2007-06-08 10:29:37
And what would be the practical use of the efficiently packed MP3s? Even arithmetic coded JPEGs are not safe for archival because of little support in programs.
Title: MP3 repacker
Post by: smack on 2007-06-08 11:01:31
And what would be the practical use of the efficiently packed MP3s? Even arithmetic coded JPEGs are not safe for archival because of little support in programs.

We're talking about an archiver that could be able to compress mp3's losslessly. Just think of it like zip-/rar-ing your collection of mp3 files in order to save some storage space, with the difference that the hypothetical archiver would compress mp3's much better than zip or rar. These archive files wouldn't be supported by existing mp3 players, of course.

btw. nemoW has provided a link to SoundSlimmer which appears to do exactly what we're discussing here. So it already exists, the question is: when will the first open-source program surface that works even better than that? 
Title: MP3 repacker
Post by: psyllium on 2007-06-11 08:04:45
First of all, I have to say I am very impressed with the performance of the '-z' option! This is particularly true for files that have been recorded on a device doing its own hardware encoding (in this case, an iKey Plus recorder).

The original file: 320kbps
Converted to vbr without -z: 306kbps
Converted to vbr with -z: 165kbps

I have checked the decoded WAV files and did a bit compare on them, and of course the output files are perfectly identical.

That's nearly HALF the size! This leads me to believe the encoder on this portable device isn't really up to scratch! I had a feeling this was the case anyway, and had been using WAV recording on the device for more important applications.

Anyway this means the 'super-squeeze' option will come in handy for compressing mp3s recorded on the device so they can be uploaded/downloaded faster.
Title: MP3 repacker
Post by: psyllium on 2007-06-11 13:00:05
The original file: 320kbps
Converted to vbr without -z: 306kbps
Converted to vbr with -z: 165kbps


For the hell of it, I tried squeezing the same file with version 1.16 of mp3packer. It gave me a file of pretty much the same size, I'm not sure whether this is symptomatic of the recording device or its encoding algorithm though. For the 4h30m VBR mp3 file, it took 37 minutes to process in version 1.18 instead of 25 minutes in 1.16. Do you think we could have an option for a 'normal' squeeze (1.16 behaviour), as well as a 'super' squeeze (1.18 behaviour)? No big deal if not, I can use 1.16 still .

Chris.
Title: MP3 repacker
Post by: Omion on 2007-06-12 06:58:11
The original file: 320kbps
Converted to vbr without -z: 306kbps
Converted to vbr with -z: 165kbps


For the hell of it, I tried squeezing the same file with version 1.16 of mp3packer. It gave me a file of pretty much the same size, I'm not sure whether this is symptomatic of the recording device or its encoding algorithm though. For the 4h30m VBR mp3 file, it took 37 minutes to process in version 1.18 instead of 25 minutes in 1.16. Do you think we could have an option for a 'normal' squeeze (1.16 behaviour), as well as a 'super' squeeze (1.18 behaviour)? No big deal if not, I can use 1.16 still .

Chris.

Blarg. I knew someone would ask for that. For right now, the answer is no, because I changed around a lot of the data types when moving to the new -z switch, so everything would have to be re-written. I was thinking of doing sort of a -z1 -z2 -z3 thing, but that may take a while.

By the way, what were the actual final file sizes?
Title: MP3 repacker
Post by: psyllium on 2007-06-13 13:01:11
Blarg. I knew someone would ask for that. For right now, the answer is no, because I changed around a lot of the data types when moving to the new -z switch, so everything would have to be re-written. I was thinking of doing sort of a -z1 -z2 -z3 thing, but that may take a while.

By the way, what were the actual final file sizes?


I've just recorded a smaller snippet this time around to test it out:
Original file: 1319706 bytes (320kbps CBR)
'mp3packer': 1242296 bytes (301kbps VBR) 94.1%
'mp3packer -z 1.16': 628042 bytes (152kbps VBR) 47.6%
'mp3packer -z 1.18': 627689 bytes (152kbps VBR) 47.6%

As you can see, this recording device is wasting a lot of space! It must be the packet compressing algorithm? But either way the 1.18 -z option doesn't seem to squeeze it that much more. I can provide a sample if you need it.
Title: MP3 repacker
Post by: Ojay on 2007-06-30 16:59:55
Hmmm, I just tried MP3packer with the new LAME3.98b4. The new vbr-code seems to produce a lot of padding (in contrast to LAME3.97, I checked that). I was able to use mp3packer to reduce the bitrate from 231 to 227 (lame parameters: -V0 --vbr-new -b32).

4kbps padding removed with mp3packer :-)
Title: MP3 repacker
Post by: PHOYO on 2007-07-02 21:33:57
Hmmm, I just tried MP3packer with the new LAME3.98b4. The new vbr-code seems to produce a lot of padding (in contrast to LAME3.97, I checked that). I was able to use mp3packer to reduce the bitrate from 231 to 227 (lame parameters: -V0 --vbr-new -b32).

4kbps padding removed with mp3packer :-)


Yes, I noticed that too. That's pretty strange. I think LAME's vbr routine should be as efficient as possible. Is there any LAME developer here to explain this behaviour?

OT: --vbr-new isn't needed anymore in 3.98. -b32 is also unnecessary.
Title: MP3 repacker
Post by: Jojo on 2007-07-04 19:39:02
it might have something to do with the strict ISO enforcement Lame 3.98 uses
Title: MP3 repacker
Post by: numbskull on 2007-07-11 07:00:13
There is any advantage in converting cbr 192 to vbr (using -preset standard)?

Also, there is no loss depending on LAME version used in the original encoded file or the LAME used in the new file? I'm asking this because I still use LAME 3.90.3 --preset standard, and I'm yet scared to repack my 320kbps files, don't want any quality loss or other kind of problem.
Title: MP3 repacker
Post by: Omion on 2007-07-11 07:10:38
There is any advantage in converting cbr 192 to vbr (using -preset standard)?

If you transcode CBR-192 to --preset standard, there will be quality loss. However, that is not something that mp3packer does.

Quote
Also, there is no loss depending on LAME version used in the original encoded file or the LAME used in the new file? I'm asking this because I still use LAME 3.90.3 --preset standard, and I'm yet scared to repack my 320kbps files, don't want any quality loss or other kind of problem.

There will be no quality loss repacking to CBR-320. However, there will be no quality gain either. Unless you absolutely need CBR, don't repack to CBR-320.

I think you may be misunderstanding exactly what mp3packer does. The main thing to realize is that it does not change quality at all; it only changes file size. If you want higher quality MP3 files, re-rip from the source. If you want slightly smaller MP3 files, that's what mp3packer is good at.
Title: MP3 repacker
Post by: MatMaul on 2007-07-12 12:42:13
hello !

thanks to you Omion for this great tool !

I propose 2 new functionalities :

--avoid-fhgdec-bug to generate mp3 file "compatibles" with the FHG decoder like lame 3.98b4

--strictly-enforce-ISO to do like the switch in lame too 

I don't know if it is possible to do that losslessly, but if it is possible I think it can be useful.
Title: MP3 repacker
Post by: Omion on 2007-07-14 04:27:45
Those are good ideas, but only the encoder can control either of them.

The FHG bug deals with the maximum Huffman value. mp3packer does not change these values (and it is generally impossible to do losslessly), it only changes how they are encoded.

The strictly-enforce-iso switch in LAME will lower the maximum amount of data in one frame. However, mp3packer will either not change the amount of data in a frame (without -z), or it will lower it (with -z). This means that a file repacked with -z may have the issue fixed, but it's impossible to always fix it.

The good news is that if the input file does not suffer from either of these issues, the output file won't either.
Title: MP3 repacker
Post by: numbskull on 2007-07-15 07:37:25
Quote
I think you may be misunderstanding exactly what mp3packer does. The main thing to realize is that it does not change quality at all; it only changes file size. If you want higher quality MP3 files, re-rip from the source. If you want slightly smaller MP3 files, that's what mp3packer is good at.


I understood the program function, I just don't made myself clear enough 

So then using repacker on my 320cbr files will produce smaller files without quality loss at all?
I was worried about the "depending on the LAME version used" described in the program functions.

Another question: if the original files are ripped with other enconder than LAME, repacking them using LAME will have any quality loss/problem ?
Title: MP3 repacker
Post by: pdq on 2007-07-15 19:43:18
So then using repacker on my 320cbr files will produce smaller files without quality loss at all?
I was worried about the "depending on the LAME version used" described in the program functions.

Another question: if the original files are ripped with other enconder than LAME, repacking them using LAME will have any quality loss/problem ?


There will be no change in quality at all regardless of which encoder/settings had been used. The decoded output will be identical. The "depending on the LAME version" had to do only with how well a file repacks.

As for repacking, LAME has nothing to do with this. The repacking is done entirely by MP3 repacker and nothing else.
Title: MP3 repacker
Post by: Ojay on 2007-07-15 19:59:47
The FHG bug deals with the maximum Huffman value. mp3packer does not change these values (and it is generally impossible to do losslessly), it only changes how they are encoded.

The strictly-enforce-iso switch in LAME will lower the maximum amount of data in one frame. However, mp3packer will either not change the amount of data in a frame (without -z), or it will lower it (with -z). This means that a file repacked with -z may have the issue fixed, but it's impossible to always fix it.


That sounds very interesting! mp3packer might "repair" the mp3 decoding issue by using the -z switch. What would be the percentage of "fixing" by using the -z switch? 50%, 90%, 99% ?? That would be interesting to know.
Title: MP3 repacker
Post by: Skylined ;)~ on 2007-07-16 08:26:23
Just tried it again and my results

Black Sabbath (2002) Symptom Of The Universe (1970-78)

Using FhG MP3 Encoder 4.0.3 (dbpoweramp Reference) at 320kbps
Using High Quality setting.

Original: 29 files, 348.9 MB, 320.0 kbps
Result: 29 files, 301.0 MB, 275.4 kbps

Hmmm, almost 14% reduction...
this is results using Super-squeeze -z option which is quite slow ;( on a p3 800
with the default settings it actually added 1kb to all the files.

-z
This option makes mp3packer actually decode the audio, do a brute-force search for optimal encoding parameters, then re-encode it. It is quite a bit safer than the old -z switch, but it increases the time to repack the files dramatically. On my computer, a 4-minute file which would get repacked in the blink of an eye would take around 30 seconds with this option enabled.

are you sure it wont change the quality of my files... I am looking at the words :RE-ENCODE:
also, does it werk with mp3pro or 6 channel mp3surround files?

I have a ton of CBR fhg files for I once used all the buggy Fhg encoders until 2005 when i discovered this place... I tried the result all over, in the car, portable, Hifi and headphones and no diff.

But again lovely proggie, keeps my ID tags and APEv2 with RG where applicable.
Title: MP3 repacker
Post by: Ojay on 2007-07-16 09:24:37
-z
This option makes mp3packer actually decode the audio, do a brute-force search for optimal encoding parameters, then re-encode it.

(...)

are you sure it wont change the quality of my files... I am looking at the words :RE-ENCODE:
also, does it werk with mp3pro or 6 channel mp3surround files?


Two things:

1.) mp3packer is not lossy! mp3 files are encoded (by encoders) in a 2-pass process, first the audio data are lossily reduced and encoded and then in a second pass the result is being zipped (so to say).  The -z switch unzips the audio data (reverses the 2nd pass) but actually does not decode the audio data. Therefore it is actually indeed lossless. mp3packer then re-zips the audio data ( -z means "zipping") with somewhat more brute force methods so that the compression of the zipped mp3 file is finally higher. That's it.

2.) mp3surround files are destroyed by mp3packer! For mp3pro I have no idea but mp3surround is actually a normal stereo mp3 that follows the MPEG-1 specs. To do that it is necessary to store the surround info (call it a "joint surround channel") outside the normal frame data (as "padding"). Padding is (as far as I know) only defined for 44.1kHz mp3 files so mp3surround is only possible for 44.1kHz sampling frequencies.

Now, what is mp3packer doing: it strips off padding from 44.1 kHz mp3 files. As a consequence, any mp3surround info will be removed from the file by mp3packer, you will get a "normal" stereo file instead. Up to now it is not possible for mp3surround files "to survive" an mp3packer pass. So better you do not use mp3packer with mp3surround mp3 files.
Title: MP3 repacker
Post by: Skylined ;)~ on 2007-07-16 09:43:52
thanks for the heads up, still what about mp3pro? anyone

Started converting a 40gb drive just now with -z
Title: MP3 repacker
Post by: Ojay on 2007-07-16 10:13:29
thanks for the heads up, still what about mp3pro? anyone

make a backup copy of an mp3pro file, then use mp3packer with the file and after that try to play it with the mp3pro player. If it works, then (likely) okay, otherwise stop using mp3packer with mp3pro files.

Report the result here, please.
Title: MP3 repacker
Post by: abasher on 2007-07-16 11:23:26
thanks for the heads up, still what about mp3pro? anyone

Started converting a 40gb drive just now with -z

Doesn't using this program on MP3PRO files somewhat defeat it's purpose? MP3 Repacker removes padding, which is almost only available in real high bitrate MP3s. MP3PRO is aimed for very low bitrates, and should be struggling to deliver decent sound -> not pad.
Title: MP3 repacker
Post by: pdq on 2007-07-16 11:29:42
The -z option should potentially provide savings at any bitrate.
Title: MP3 repacker
Post by: MatMaul on 2007-07-16 12:21:57
Those are good ideas, but only the encoder can control either of them.

The FHG bug deals with the maximum Huffman value. mp3packer does not change these values (and it is generally impossible to do losslessly), it only changes how they are encoded.

The good news is that if the input file does not suffer from either of these issues, the output file won't either.


thanks for your answer.

but there is something I do not understand.
lame developers said the bitrate increase at V0 in 3.98 version is because of the fhg fix.

I have made some tests on a track at V0 :
3.97 : 254 kbps
3.98 : 264 kbps

and I used mp3packer on those compressed tracks :
3.97 : 254 kbps
3.98 : 256 kbps

so the bitrate increase seems to disappear when I use mp3packer.
are you sure mp3packer doesn't "break" the fhg fix ?
Title: MP3 repacker
Post by: menno on 2007-07-16 13:31:17
so the bitrate increase seems to disappear when I use mp3packer.
are you sure mp3packer doesn't "break" the fhg fix ?


No, it actually fixes the broken <=3.97 files instead of breaking the 3.98 files.
Title: MP3 repacker
Post by: menno on 2007-07-16 13:54:33

so the bitrate increase seems to disappear when I use mp3packer.
are you sure mp3packer doesn't "break" the fhg fix ?


No, it actually fixes the broken <=3.97 files instead of breaking the 3.98 files.


That's with default options...

I tried:

mp3packer -b 320 -R file.mp3

and that creates invalid files (also from LAME 3.98).
The author of this tool should read: http://www.hydrogenaudio.org/forums/index....showtopic=40308 (http://www.hydrogenaudio.org/forums/index.php?showtopic=40308)
Title: MP3 repacker
Post by: Antonski on 2007-07-16 14:39:23
2.) mp3surround files are destroyed by mp3packer! For mp3pro I have no idea but mp3surround is actually a normal stereo mp3 that follows the MPEG-1 specs. To do that it is necessary to store the surround info (call it a "joint surround channel") outside the normal frame data (as "padding"). Padding is (as far as I know) only defined for 44.1kHz mp3 files so mp3surround is only possible for 44.1kHz sampling frequencies.


thanks for the heads up, still what about mp3pro? anyone


I tried with mp3pro, no luck.
In both cases, with and without -z option the result files are smaller:

original :        4184422    100%
repacked :      3949402      94%
repacked,-z :  3863238      92%

However, in both cases the repacked file is not recognized as mp3pro anymore. It is played as mp3 at 22 kHz.
So, if mp3pro rely on some side information (as mentioned for the mp3surround), this info is apparently removed by the repacking.
~
Title: MP3 repacker
Post by: Bruno Monteiro on 2007-07-16 19:38:20
Did a quick test with the -z flag, here are the results:

Original: 1424 MB
Packed: 1338 MB

Ratio: 94,0%

Some albums didn't compress at all (a few KB only), while others got 85% ratio  (15% off). While I couldn't find the pattern (encoder, stereo mode, genre), I greatly appreciate this tool.

Great work!!! 

The only thing missing (for now) would be dual-core support!
Title: MP3 repacker
Post by: Omion on 2007-07-17 03:50:17
@Antonski:
Yeah. mp3packer will throw away mp3pro info. mp3pro is just mp3 with extra info added, and mp3packer only keeps the part that's actually mp3. The extra info is tagged as garbage and thrown out. I think I mentioned that somewhere earlier in the thread, but it's getting a bit long to read it all...
Title: MP3 repacker
Post by: Bruno Monteiro on 2007-07-20 14:41:34
@Antonski:
Yeah. mp3packer will throw away mp3pro info. mp3pro is just mp3 with extra info added, and mp3packer only keeps the part that's actually mp3. The extra info is tagged as garbage and thrown out. I think I mentioned that somewhere earlier in the thread, but it's getting a bit long to read it all...


Though some "garbage" is thrown out, I appreciate the LYRICS tag (just started using them) not being discarded. So it only discards not useful metadata? Or has no influence in metadata whatsoever? Thanks!
Title: MP3 repacker
Post by: pdq on 2007-07-20 18:00:29
I believe you will find that actual metadata is preserved. What is thrown away is extra data within the data frames that are not part of the audio data itself.
Title: MP3 repacker
Post by: Ojay on 2007-07-21 12:15:02
I believe you will find that actual metadata is preserved. What is thrown away is extra data within the data frames that are not part of the audio data itself.
APEv2 tags will be removed.
Title: MP3 repacker
Post by: numbskull on 2007-07-23 02:45:26
I'm getting very small reduction, almost every frame remains 320

Am I doing something wrong? I'm using "mp3repacker -z"

From 98 mb -> 96 mb from one CD

From 55 mb -> 54 mb from another one
Title: MP3 repacker
Post by: Mangix on 2007-07-23 02:50:35
that's normal. i guess that the mp3(s) were encodec VERY well.
Title: MP3 repacker
Post by: RogerG on 2007-07-23 18:56:23
In the manual you say about the debug option:
Quote
It is recommended that you redirect the output to a file, as the information gets quite verbose.


How can this be done? Have I missed the explanation somewhere?

Roger
Title: MP3 repacker
Post by: MedO on 2007-07-23 19:21:23
In the manual you say about the debug option:
Quote

It is recommended that you redirect the output to a file, as the information gets quite verbose.


How can this be done? Have I missed the explanation somewhere?

Roger


To redirect stdout to a file, you add ">filename.ext" to your commandline. So in this case, you might write
Code: [Select]
mp3packer --debug "all" test.mp3 >debug.txt


Edit: Be careful with this, it can produce text files in the hundreds of megabytes. At least, it did this in my little test just now.
Title: MP3 repacker
Post by: RogerG on 2007-09-18 15:27:13
Hi!
I have a request:
It would be nice if mp3repacker would print the time on Sync errors in addition to the frame number. Then I could easily find that position with my mp3 player and look how the error sounds.

Ciao!
Title: MP3 repacker
Post by: kwanbis on 2007-09-29 22:10:34
Sorry if it was discussed already, but the topic is already too long.

I run mp3recpacker on 2932 files, and it came up bigger! how can that be?

2932 items successfully processed and 100 items copied (In: -1732313922 bytes, Out: -1836620697 bytes).

0.0 % decrease in size.

0 items failed.

PS: i used -s -t as parameters, and runned it from WinMP3Packer.
Title: MP3 repacker
Post by: MedO on 2007-09-29 22:21:00
2932 items successfully processed and 100 items copied (In: -1732313922 bytes, Out: -1836620697 bytes).


From the numbers, it looks like a signed int is used for the number of bytes, which overflowed (possibly more than once, considering the number of files). So it's just a display error, the files actually became ~100MiB smaller in the process if that interpretation is correct.
Title: MP3 repacker
Post by: kwanbis on 2007-09-29 22:23:32
thanks for the response, but in any case, it looks like it got 100 MiB bigger, or i'm not seeing something?
Title: MP3 repacker
Post by: Nick.C on 2007-09-29 22:25:43
If it's counting upwards from -(2^31) then it would be circa 100MiB less rather than more...
Title: MP3 repacker
Post by: Omion on 2007-09-30 06:52:56

2932 items successfully processed and 100 items copied (In: -1732313922 bytes, Out: -1836620697 bytes).


From the numbers, it looks like a signed int is used for the number of bytes, which overflowed (possibly more than once, considering the number of files). So it's just a display error, the files actually became ~100MiB smaller in the process if that interpretation is correct.

Oh dear. You overflowed my integers. The max number OCaml can support is 2^30 - 1, so if you convert more than a gigabyte of songs it will give negative numbers.

The way integers overflow, you can still do standard math on them, so you saved (-1732313922)-(-1836620697)=104306775 bytes. The output is numerically less than the input, so you did actually save space.

I'll change that in the next version (whenever that comes out...  )

[edit] Wait a second... that's a WinMP3Packer message! You had me looking through my source for quite a while!  The command line gives no indication as to how many bytes were saved. It's all yours, psyllium! 


@RogerG:
Sorry about the delay. I guess I missed the update notification.
I'll see if it's easy to add a time to the error, instead of the frame number. It shouldn't be too hard to figure it out. In the meantime, you can actually do the math yourself:
44.1KHz: Seconds = Frame * 0.026122449
48KHz: s = f * 0.024
32KHz: s = f * 0.036

That equation is generally accurate. It depends on the starting offset stored in the XING tag, but it's never too far off.

[edit2]Now included in 1.19 (http://omion.dyndns.org/mp3packer/mp3packer-1.19.rar).
Title: MP3 repacker
Post by: kwanbis on 2007-09-30 15:55:59
thanks for the info
Title: MP3 repacker
Post by: LigH on 2007-10-16 12:35:48
Could you please add an option for those who "ab-use" MP3Packer to create "optimal CBR" MP3 files, to simply use the detected minimum CBR bitrate and convert the file in a second pass right away (in one application call)? Or is your tool not made for 2 passes after each other?

As far as I understood (oh, well, english is not my native language, and the topic is already quite grown), for now I need to run the tool once, note down the detected minimum CBR bitrate, and enter it in a second call with different parameters.
Title: MP3 repacker
Post by: Gnerma on 2007-10-18 12:32:12
Here is a fun aside.

I recently ran mp3packer -z on the new Radiohead album In Rainbows which is currently only available from inrainbows.com as a 160 kbps CBR LAME encode. This shaved 862,407 bytes from the album. Supposedly the album has been downloaded from the site 1.2 million times so far. If Radiohead had bothered to run mp3packer on In Rainbows they would have saved over 963 GB of upload bandwidth to date (nearly a terabyte).
Title: MP3 repacker
Post by: gramouk on 2007-10-18 16:54:45
Hi everyone!!!

I'm the bloke using a Mac and cdj's!
The easiest solution was to find a pc, hook on my drive and process all my vbrs.
Thing is: whatever i do, files are always output to 320kbps, whereas they only have a vbr bitrate of eg.182.
I want them to be 192, no point having them at 320.
can somone help me out.
thankyou
Title: MP3 repacker
Post by: j7n on 2007-10-18 17:21:42
One of the points of Radiohead using exactly 160 kBit/s was that CBR is supposedly more compatible than VBR. They could just use VBR in the first place instead of creating a pseudo-variable bitrate files in mp3packer.

The constant bitrate must be high enough to fit the largest frame (it's more complex if you remember the bit reservoir). In 182 kBit/s VBR the instantenous bitrate may and usually is significantly higher than 192 kBit/s.
Title: MP3 repacker
Post by: gramouk on 2007-10-18 17:46:21
ok, which means you get a 256 or a 320kbps file most of the time whan converting vbr to cbr...???
If its normal its cool, but I wanna be shure before doing this to all my library!!! Because it kinda makes files much bigger.
thanx
Title: MP3 repacker
Post by: j7n on 2007-10-18 19:21:13
I ran mp3packer on one of my files. It has avg bitrate of 187 kBit/s.

mp3packer.exe -b 256 -z 10.mp3

In this file mp3packer created quite many 320 kBit frames in places where original file had the highest overall bitrate. Whole file was pseudo-variable bitrate with 256 and 320 kbit frames. If you need all frames of equal data length then 320 kBit/s is the only choice on "--preset standard" - like encodes. Lower rate mono files might not need that much, but I don't really know a safe way to find out this without trial and error.
Title: MP3 repacker
Post by: gramouk on 2007-10-18 20:06:28
OK, thanx! I guess I'm gonna loose some space, but at least I can use my CDJs!
Do you recommend to use -z ???
Title: MP3 repacker
Post by: j7n on 2007-10-18 20:25:03
Z gives the smallest possible data length. I used it to test if it's possible to avoid 320 kBit frames at all. For simple conversion to CBR z is of no use since you'll have the max bitrate anyway.
Title: MP3 repacker
Post by: tgoose on 2007-10-21 11:42:11
I can't make this, I get a long output:

Code: [Select]
r$ make
ocamlopt -c crc.ml
ocamlopt list2.mli
ocamlopt -c list2.ml
ocamlopt expandarray.mli
ocamlopt -c expandarray.ml
ocamlopt c_part.c
ocamlopt -c mp3types.ml
ocamlopt -c pack.ml
ocamlopt -c mp3types.cmx pack.cmx mp3read.ml
File "mp3read.ml", line 164, characters 7-18:
Warning Y: unused variable return_none.
ocamlopt -c expandarray.cmx mp3types.cmx pack.cmx mp3read.cmx mp3info.ml
ocamlopt -c mp3types.cmx pack.cmx mp3framehuffman.ml
ocamlopt -c mp3types.cmx pack.cmx mp3framehuffman.cmx mp3frameutils.ml
ocamlopt -c list2.cmx mp3types.cmx pack.cmx mp3read.cmx mp3framehuffman.cmx mp3frameutils.cmx mp3queue.ml
File "mp3queue.ml", line 326, characters 6-18:
Warning Y: unused variable bitrate_list.
File "mp3queue.ml", line 375, characters 5-18:
Warning Y: unused variable print_bitrate.
File "mp3queue.ml", line 361, characters 5-26:
Warning Y: unused variable update_side_reservoir.
File "mp3queue.ml", line 410, characters 28-3037:
Warning P: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
{side_bits=[|  |]}
File "mp3queue.ml", line 469, characters 18-2462:
Warning P: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
{side_bits=[|  |]}
File "mp3queue.ml", line 527, characters 24-1596:
Warning P: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
{side_bits=[|  |]}
File "mp3queue.ml", line 567, characters 14-1750:
Warning P: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
{side_bits=[|  |]}
ocamlopt -o mp3packer unix.cmxa str.cmxa crc.cmx list2.cmx expandarray.cmx c_part.obj mp3types.cmx pack.cmx mp3read.cmx mp3info.cmx mp3framehuffman.cmx mp3frameutils.cmx mp3queue.cmx mp3packer.ml
/usr/bin/ocamlopt: don't know what to do with c_part.obj.
Usage: ocamlopt <options> <files>
Options are:
  -ffast-math  Inline trigonometric and exponential functions
  -a  Build a library
  -c  Compile only (do not link)
  -cc <comp>  Use <comp> as the C compiler and linker
  -cclib <opt>  Pass option <opt> to the C linker
  -ccopt <opt>  Pass option <opt> to the C compiler and linker
  -compact  Optimize code size rather than speed
  -config  print configuration values and exit
  -dtypes  Save type information in <filename>.annot
  -for-pack <ident>  Generate code that can later be `packed' with
    ocamlopt -pack -o <ident>.cmx
  -i  Print inferred interface
  -I <dir>  Add <dir> to the list of include directories
  -impl <file>  Compile <file> as a .ml file
  -inline <n>  Set aggressiveness of inlining to <n>
  -intf <file>  Compile <file> as a .mli file
  -intf-suffix <file>  Suffix for interface files (default: .mli)
  -intf_suffix <file>  (deprecated) same as -intf-suffix
  -labels  Use commuting label mode
  -linkall  Link all modules, even unused ones
  -noassert  Don't compile assertion checks
  -noautolink  Don't automatically link C libraries specified in .cma files
  -nolabels  Ignore non-optional labels in types
  -nostdlib  do not add standard directory to the list of include directories
  -o <file>  Set output file name to <file>
  -output-obj  Output a C object file instead of an executable
  -p  Compile and link with profiling support for "gprof"
    (not supported on all platforms)
  -pack  Package the given .cmx files into one .cmx
  -pp <command>  Pipe sources through preprocessor <command>
  -principal  Check principality of type inference
  -rectypes  Allow arbitrary recursive types
  -S  Keep intermediate assembly file
  -thread  Generate code that supports the system threads library
  -unsafe  No bounds checking on array and string access
  -v  Print compiler version and standard library location and exit
  -version  Print compiler version and exit
  -verbose  Print calls to external commands
  -w <flags>  Enable or disable warnings according to <flags>:
    C/c enable/disable suspicious comment
    D/d enable/disable deprecated features
    E/e enable/disable fragile match
    F/f enable/disable partially applied function
    L/l enable/disable labels omitted in application
    M/m enable/disable overriden methods
    P/p enable/disable partial match
    S/s enable/disable non-unit statement
    U/u enable/disable unused match case
    V/v enable/disable hidden instance variables
    Y/y enable/disable suspicious unused variables
    Z/z enable/disable all other unused variables
    X/x enable/disable all other warnings
    A/a enable/disable all warnings
    default setting is "Aelz"
  -warn-error <flags>  Treat the warnings of <flags> as errors, if they are
    enabled.  See option -w for the list of flags.
    Default setting is "a" (warnings are not errors)
  -where  Print location of standard library and exit
  -nopervasives  (undocumented)
  -dparsetree  (undocumented)
  -drawlambda  (undocumented)
  -dlambda  (undocumented)
  -dcmm  (undocumented)
  -dsel  (undocumented)
  -dcombine  (undocumented)
  -dlive  (undocumented)
  -dspill  (undocumented)
  -dsplit  (undocumented)
  -dinterf  (undocumented)
  -dprefer  (undocumented)
  -dalloc  (undocumented)
  -dreload  (undocumented)
  -dscheduling  (undocumented)
  -dlinear  (undocumented)
  -dstartup  (undocumented)
  - <file>  Treat <file> as a file name (even if it starts with `-')
  -help  Display this list of options
  --help  Display this list of options
make: *** [mp3packer] Error 2


This is on Ubuntu Gutsy, I installed the ocaml and a few other packages to be on the safe side. I have absolutely no idea about ocaml so I may be doing something idiotic.
Title: MP3 repacker
Post by: Antonski on 2007-10-21 15:21:53
I can't make this, I get a long output:
...


I really sorry that it is not written in pure perl anymore.
All these troubles with compilers ... :|
Title: MP3 repacker
Post by: robert on 2007-10-21 15:50:06
Code: [Select]
/usr/bin/ocamlopt: don't know what to do with c_part.obj.
I've never tried ocaml, nor did I try to build this project. You may want to find out, if the c_part.c files has been compiled and try to locate the object file. Maybe it was build under a different name and simply renaming it to c_part.obj will do.
Title: MP3 repacker
Post by: Omion on 2007-10-21 19:03:02
I can't make this, I get a long output:

...

This is on Ubuntu Gutsy, I installed the ocaml and a few other packages to be on the safe side. I have absolutely no idea about ocaml so I may be doing something idiotic.


Run "make OBJ_EXT=.o" instead of just "make"

mp3packer uses a C file for changing priority, which will compile to a .obj file on Windows, but a .o file on everything else. I couldn't find a way to handle both cases automatically, so it has to be specified on the command line.

That should be the only error you run into. Everything else in that code is a warning
Title: MP3 repacker
Post by: tgoose on 2007-10-22 09:12:32

I can't make this, I get a long output:

...

This is on Ubuntu Gutsy, I installed the ocaml and a few other packages to be on the safe side. I have absolutely no idea about ocaml so I may be doing something idiotic.


Run "make OBJ_EXT=.o" instead of just "make"

mp3packer uses a C file for changing priority, which will compile to a .obj file on Windows, but a .o file on everything else. I couldn't find a way to handle both cases automatically, so it has to be specified on the command line.

That should be the only error you run into. Everything else in that code is a warning

Thanks, sorted! I'll investigate the actual running after work.
Title: MP3 repacker
Post by: LigH on 2007-10-22 10:17:02
Excuse my boldness to raise my issue...

Even just a "no vs. maybe" statement would be appreciated, regarding an auto-max-cbr switch.
Title: MP3 repacker
Post by: Omion on 2007-10-22 16:44:48
Excuse my boldness to raise my issue...

Even just a "no vs. maybe" statement would be appreciated, regarding an auto-max-cbr switch.

Sorry about that. Currently the program is, as you said, only designed for one-pass operation - it would be difficult to add in a two-pass setting. However, I have been thinking of adding support for this once I add multi-threading support. I've just been thinking about how, exactly, to do that. So the answer is yes, but I don't know when.

I may be able to work on it today, actually. I'm supposed to be at work, but there are a lot of fires around San Diego, and it looks like UCSD is closed because of the smoke.  So... I'm home today.
Title: MP3 repacker
Post by: llama peter on 2007-10-23 17:15:34

I can't make this, I get a long output:

...

This is on Ubuntu Gutsy, I installed the ocaml and a few other packages to be on the safe side. I have absolutely no idea about ocaml so I may be doing something idiotic.


Run "make OBJ_EXT=.o" instead of just "make"

mp3packer uses a C file for changing priority, which will compile to a .obj file on Windows, but a .o file on everything else. I couldn't find a way to handle both cases automatically, so it has to be specified on the command line.


This might make it less instead of more portable, but if you use the C compiler directly instead of having ocamlopt call the C compiler, you can set the object file name.
change from:
c_part$(OBJ_EXT): c_part.c
        ocamlopt c_part.c

to:
c_part$(OBJ_EXT): c_part.c
        $(CC) $(CFLAGS) -c -o $@ $^

Oh, there's an ocamlopt option -ccopt.  Maybe -ccopt "-o $@" would work.  If you're not familiar with Makefile implicit variables, you could just write it out ("-o c_part$(OBJ_EXT)").  I like writing compact makefiles that use pattern rules, like
Code: [Select]
%.cmx: %.ml
[tab] ocamlopt -c $^
%.$(OBJ_EXT): %.c:
[tab] $(CC) $(CFLAGS) -c -o $@ $^

...
mp3info.cmx: expandarray.cmx mp3types.cmx pack.cmx mp3read.cmx mp3info.ml
crc.cmx: crc.ml
pack.cmx: pack.ml
...


You just tell make about the dependencies, and it puts them all on the command line automatically. (because that's what $^ expands to.)  See the make info page...

Also, I'd suggest removing the --nice option altogether when it's not going to do anything.  Currently the help lies, because --nice does nothing on non-win32.  Or you could look at setpriority(2).
Code: [Select]
#include <sys/time.h>
#include <sys/resource.h>
...
setpriority(PRIO_PROCESS, 0, 10);


Nice job on a neat program.  I had no trouble with it on Ubuntu Gutsy (amd64).

However, what I was really looking for when I found this thread was a program to turn a stereo mp3 into a mono mp3 by dropping one of the channels.  I have some audiobooks which someone foolishly encoded as stereo (and not even joint stereo).  It's only 80kb/s with some noticeable artifacting, so I don't want to transcode it.

I already found earlier in this thread that you were going to add that feature to mp3packer, but it was incompatible with the design of the program.  Do you know of any other program that could do it?  Or would you consider making a separate tool to do it?  Or maybe just not have mp3packer be able to optimize the hell out of an mp3 at the same time its dropping channels.  So making an optimized mp3 would be a two step process.
Title: MP3 repacker
Post by: _mik on 2007-10-24 12:16:07
I already found earlier in this thread that you were going to add that feature to mp3packer, but it was incompatible with the design of the program.  Do you know of any other program that could do it?  Or would you consider making a separate tool to do it?  Or maybe just not have mp3packer be able to optimize the hell out of an mp3 at the same time its dropping channels.  So making an optimized mp3 would be a two step process.

It's a feature I have requested some time ago. I also have another question concerning it: can the removal of a channel be done without mp3 repacking (-z)? If no, a separate tool would need to share much functionality with mp3packer. Am I right?
Title: MP3 repacker
Post by: maadjordan on 2007-11-01 08:17:01
omion.. i still need a feature to dump a mp3 in raw form (un-huffman coded) and to pack this raw data later to mp3.. this to help me look for best lossless archivers for mp3 and to ease it development.. so please add it in next version or provide it as seperate tool would be even much better..

there already work in progress on jpeg-lossless compression. it reached min. 17% reduction

http://www.elektronik.htw-aalen.de/packJPG/ (http://www.elektronik.htw-aalen.de/packJPG/)

so i'm looking a mp3 solution.. please help
Title: MP3 repacker
Post by: NightsBird on 2007-11-06 12:14:37
Hello,
I use the -z switch with mp3packer1.19-180 on mp3 320kbit/s CBR files.
115 197 713 bytes
begins
115 210 236 bytes
So, that makes my MP3 bigger. Do I do something wrong ?
(http://4bleu.free.fr/WinMP3Packer.png)
Title: MP3 repacker
Post by: DoomzDayz on 2007-11-06 12:33:10
I repacked with -z a 320 CBR file that had silence in the beginning with the minimum bitrate set to both auto and 32, but the frame size as reported by winamp says it goes between 320 and 256 kbps.  Why isn't it 32 or at least lower than 256 for silence?
Title: MP3 repacker
Post by: Omion on 2007-11-08 23:49:55
Hello,
I use the -z switch with mp3packer1.19-180 on mp3 320kbit/s CBR files.
115 197 713 bytes
begins
115 210 236 bytes
So, that makes my MP3 bigger. Do I do something wrong ?

It looks like the output is larger than the input, but not by much (2KB / 115MB, or 0.01%) There is one case when mp3packer will create larger output files - all the output files have XING tags, so if the input files don't, it will add about 100 bytes to each file. Normally this is overshadowed by the savings in the rest of the files, but if the files are incompressible it will show up as a slight size increase.

I repacked with -z a 320 CBR file that had silence in the beginning with the minimum bitrate set to both auto and 32, but the frame size as reported by winamp says it goes between 320 and 256 kbps.  Why isn't it 32 or at least lower than 256 for silence?

The most likely explanation is that Winamp is not reporting those frames. I don't remember exactly how Winamp displays the frame information, but it could easily skip over reporting the silent frames.

If you want to see how many of each frame there is, run the output file through mp3packer like this: "mp3packer -i outfile.mp3"
If it reports any 32kbps frames, then it's working properly. If not, then it may not be exactly silent there. I've seen noise-shaping algorithms that add a HUGE amount of energy above 20KHz.
Title: MP3 repacker
Post by: Antonski on 2007-11-09 09:28:36

I repacked with -z a 320 CBR file that had silence in the beginning with the minimum bitrate set to both auto and 32, but the frame size as reported by winamp says it goes between 320 and 256 kbps.  Why isn't it 32 or at least lower than 256 for silence?

The most likely explanation is that Winamp is not reporting those frames. I don't remember exactly how Winamp displays the frame information, but it could easily skip over reporting the silent frames.

If you want to see how many of each frame there is, run the output file through mp3packer like this: "mp3packer -i outfile.mp3"



Or you can use EncSpot to see the bitrate distribution, if you prefer GUI applications.

~
Title: MP3 repacker
Post by: Ojay on 2007-11-10 21:04:21
I like mp3packer so far (of course, I am using it at least 1x -2x weekly)

but there is one thing I would suggest to implement:

mp3Surround data are stored in the padding data of normal stereo mp3 files. Using mp3packer always removes the mp3Surround data, leaving a bare stereo mp3 behind. Is it possible for mp3packer not to touch the surround data?

Or if that isn't possible - can you implement checks for mp3Surround data structures, followed by a warning that the user is destroying these structures by continuing?

Thanks
Title: MP3 repacker
Post by: Omion on 2007-11-11 03:05:11
I'll look into it if you can find me something that says what to look for. That's the problem with mp3pro and mp3 surround - they aren't free standards so there isn't a nice, concise spec sheet to base my implementation off of. There are some free surround implementations, but that would require reverse-engineering the format, which I'm not in the mood for.

Actually, now that I think of it, there may not be an easy way to keep surround data in the current incarnation of mp3packer. I based the whole program off of removing the padding, so I would have to change the entire pipeline around to keep it from beginning to end. Detection, however, should be relatively easy.

[edit] Now that I've looked around, I may have found an open-source mp3-surround detector, so I'll look into using it as a base for my own. [/edit]
Title: MP3 repacker
Post by: cbrigstocke on 2007-12-18 17:26:07
I tried to make a build with the 1.19 source with Ubuntu and it didn't work.  The last one I made is 1.16 and it works fine.  I tried both "make" or "make mp3packer" with no luck.  I'm not a programmer at all.  Just a directions follower.  It's a very useful program and 1.16 works fine for me, but I like to update every so often.  Any help is appreciated.
Title: MP3 repacker
Post by: Omion on 2007-12-19 05:53:53
I tried to make a build with the 1.19 source with Ubuntu and it didn't work.  The last one I made is 1.16 and it works fine.  I tried both "make" or "make mp3packer" with no luck.  I'm not a programmer at all.  Just a directions follower.  It's a very useful program and 1.16 works fine for me, but I like to update every so often.  Any help is appreciated.

Use this line instead:
Code: [Select]
make OBJ_EXT=.o

The reason it worked with 1.16 is that I didn't have any C code. 1.19 has C code in a few places for the priority changing code, and unfortunately the output files have a different extension between Windows and everything else.

To respond (very late) to llama peter:
The problem with forcing the extensions is that the object files have to be linked with OCaml, which only knows about one type of object extension. For example, the Linux OCaml knows that a C object is *.o, and doesn't know how to handle *.obj files. The Windows OCaml knows that a C object is *.obj, and doesn't know how to handle *.o files...


PS. The really annoying thing is that the priority-changing code is only used in Windows. In Linux it is compiled to a no-op, then the OCaml-native priority-changing code is used instead. The reason it's in there is that OCaml doesn't know which OS it's running under until the program runs, so the code has to be the same in every case.
Title: MP3 repacker
Post by: cbrigstocke on 2007-12-21 16:09:01
Thanks again!  Works like a charm.
Title: MP3 repacker
Post by: ZinCh on 2008-02-16 03:05:59
is it possible to convert (loseless) mono format to stereo format (ms stereo = 0%, no audio data changed)?
Title: MP3 repacker
Post by: pdq on 2008-02-16 15:19:36
is it possible to convert (loseless) mono format to stereo format (ms stereo = 0%, no audio data changed)?

If you convert it to 0% ms then the size will double. If instead you convert it to 100% ms then the size will not increase and the quality will be identical.
Title: MP3 repacker
Post by: ZinCh on 2008-02-16 17:08:54

is it possible to convert (loseless) mono format to stereo format (ms stereo = 0%, no audio data changed)?

If you convert it to 0% ms then the size will double. If instead you convert it to 100% ms then the size will not increase and the quality will be identical.

sorry, my mistake, i mean what you say  so is it possible to do that using mp3 repacker?
Title: MP3 repacker
Post by: smack on 2008-02-17 17:01:02
is it possible to convert (loseless) mono format to stereo format (ms stereo = 0%, no audio data changed)?
If you convert it to 0% ms then the size will double. If instead you convert it to 100% ms then the size will not increase and the quality will be identical.
sorry, my mistake, i mean what you say  so is it possible to do that using mp3 repacker?

No, that kind of conversion is not possible using mp3packer.

Btw. a question very similar to yours has been discussed already in this thread:
Lossless mono to JS conversion (http://www.hydrogenaudio.org/forums/index.php?showtopic=56624&hl=)
Title: MP3 repacker
Post by: SebastianG on 2008-02-18 23:50:22
Hello, Omion!

I just downloaded the source code and I'm surprised to find code to parse all the side- and main-data parts (scalefacs, huffman bits). Exactly why do you need all of this? Isn't "main_data_beg" and all the "part_2_3_length" values good enough to determine the beginning and count of the maindata bits? (count = sum over all part_2_3_length values)

Cheers,
SG
Title: MP3 repacker
Post by: Omion on 2008-02-21 00:00:05
Hello, Omion!

I just downloaded the source code and I'm surprised to find code to parse all the side- and main-data parts (scalefacs, huffman bits). Exactly why do you need all of this? Isn't "main_data_beg" and all the "part_2_3_length" values good enough to determine the beginning and count of the maindata bits? (count = sum over all part_2_3_length values)

Cheers,
SG

It is not needed for normal operation, but the -z switch needs to actually decode the data, so most of the side info is needed. I don't use the global gain or the "pre" flag, but since I was recreating the entire side-info from my data structure it made more sense to parse them as well.

I was planning to use the scalefactors themselves to see if there was any way to optimize them, but it turned out to be useless. I didn't bother to get rid of the parsing code, and the overhead is minimal (much smaller than the time it takes to brute-force Huffman tables)

This is all assuming you're looking at mp3frameutils.ml. That's where the decoding/recoding of the mp3 data takes place, and where most of that data is actually needed. If you don't use the -z switch, this whole file is not used. In all of the other locations the side_info is represented by main_data_begin, length of each granule (in bits), and length of all granules (in bytes). Or, at least it should be... I haven't looked at the code in a while.
Title: MP3 repacker
Post by: apoc_metal on 2008-03-12 14:51:23
Anyone tried to build this on OSX?
Title: MP3 repacker
Post by: apoc_metal on 2008-03-15 21:12:32
Hey, I whipped together an OSX wrapper for this using Platypus. It's pretty primitive, but it works!

Drag 1 or more mp3 files onto the icon, and it should crank away... don't think it works for folders... it uses a perl wrapper that is easy to modify if anyone out there actually knows what they're doing (I've never touched perl before this :-p)

You can find it here: http://apoctrack.com/mp3packerX/ (http://apoctrack.com/mp3packerX/)

NOTE: it requires DARWINE available here (http://darwine.sourceforge.net/), installed in your applications folder (modify the script if it's elsewhere, or whatever)

p.s. (I tried compiling the ocaml source, but got some weird errors, so this was my Plan B)

p.p.s. Woops, I think funky characters in filenames break it... (yeah, it seems to be apostrophes) help?

here's a one line BASH script to write the new -vbr.mp3 files over their originals
Code: [Select]
for i in *-vbr.mp3; do j=`echo $i | sed 's/-vbr.mp3/.mp3/g'`; mv "$i" "$j"; done
Title: MP3 repacker
Post by: Speckmade on 2008-03-26 21:16:57
(Thanks for the great piece of software. I've been waiting for something like it for quite some time, but:)
I've run the thing on a bunch of files (shaving off more than 20 percent with some of them - impressive! -) and now the modified files seem to have different content: Pasting the inverted signal of the second file over the first shows some altered samples (the difference is just one step on the 16-bit-dynamic-range each time, most of the time several together in a small group, with about 40 such groups per minute, most of the time about 1.7 seconds apart).
foobar's bit comparison feature even reports different durations (like
Code: [Select]
Comparing failed (length mismatch : 4:24.740862 vs 4:24.778209, 11675072 vs 11676719 samples).
).

While this should not be audible I still wonder where it comes from...
Title: MP3 repacker
Post by: Omion on 2008-03-27 04:01:54
The differences in the lengths may be because Foobar is more lenient with LAME/XING headers, whereas mp3packer is tighter. The number of samples (1647) is about right for that. I've seen that happen a lot with not-quite-compliant headers.

The actual differences in the files is a bit odd, and may be because of how the file was encoded. I'll look into it.
Title: MP3 repacker
Post by: Jens Rex on 2008-03-27 05:15:33
the difference is just one step on the 16-bit-dynamic-range each time

That's probably just dithering. Try decoding the same file twice and compare. You'll probably see these "differences" there too.
Title: MP3 repacker
Post by: MedO on 2008-03-27 19:01:20
the difference is just one step on the 16-bit-dynamic-range each time

That's probably just dithering. Try decoding the same file twice and compare. You'll probably see these "differences" there too.


I think dithering would change a lot more samples than fits the description.
Title: MP3 repacker
Post by: menno on 2008-04-14 19:19:24
I have a mp3 file here with 31 frames. The first 5 don't have CRC's, all the rest does. When mp3repacker is done with this file it reports it only processed 5 frames. But the output has the right amount of frames.
Title: MP3 repacker
Post by: Omion on 2008-04-15 20:48:25
I have a mp3 file here with 31 frames. The first 5 don't have CRC's, all the rest does. When mp3repacker is done with this file it reports it only processed 5 frames. But the output has the right amount of frames.

That's because, by default, it keeps all of the stuff after the last frame. Since mp3packer only recognizes 5 frames, it repacks those and copies everything after it, which includes all the other frames.

This can result in a problem if the 6th frame depends on something in the 5th frame. mp3packer doesn't worry about it in this case since it doesn't think there is a 6th frame, but it can result in the 6th frame's data being corrupted. However, if the file is a result of splicing two MP3s together (probably how it was made) then you won't have this problem.
Title: MP3 repacker
Post by: ctsoxfan on 2008-05-06 03:04:53
This software is great! Prior to finding this, I thought the only solution was to re-encode the files (I know, not good!).

But I have one issue, and I searched and couldn't find an answer. A lot of the VBR files I am loading into this program (to convert to 320CBR) are coming up as 128CBR files, not VBR. The program thinks they are CBR files, when they definitely are not (they are mostly V2 or V0). Even the "force" setting doesn't convert these files, the program skips them. I cannot figure out a way around this. Can someone help me?
Title: MP3 repacker
Post by: menno on 2008-05-06 16:05:05

I have a mp3 file here with 31 frames. The first 5 don't have CRC's, all the rest does. When mp3repacker is done with this file it reports it only processed 5 frames. But the output has the right amount of frames.

That's because, by default, it keeps all of the stuff after the last frame. Since mp3packer only recognizes 5 frames, it repacks those and copies everything after it, which includes all the other frames.

This can result in a problem if the 6th frame depends on something in the 5th frame. mp3packer doesn't worry about it in this case since it doesn't think there is a 6th frame, but it can result in the 6th frame's data being corrupted. However, if the file is a result of splicing two MP3s together (probably how it was made) then you won't have this problem.


No it's not how it was made, it's actually one of the MPEG reference files for testing decoder conformance. Also the standard simply allows changing CRC on or off from frame to frame.
Title: MP3 repacker
Post by: gramouk on 2008-05-06 18:42:06
Thanks a lot apoc_metal !!!

Thing is your link is "not found", I found mp3packerx Here (http://blog.writenothing.com/softwares/) .

Finally a Mac version!  But I don't have an Intel based mac, is there any way you could whip out a nice little powerpc version for all us still on G4....

Thanx
Title: MP3 repacker
Post by: Omion on 2008-05-07 04:05:25
No it's not how it was made, it's actually one of the MPEG reference files for testing decoder conformance. Also the standard simply allows changing CRC on or off from frame to frame.


Actually, when I just tried to change the behavior of mp3packer, I just noticed that it should already accept different CRCs per frame, even though it doesn't... I'll see why.

I'm looking around on my conformance files here, and I assume you are talking about layer3/hecommon.bit? I'll do some tests on those files.
Title: MP3 repacker
Post by: Omion on 2008-05-07 05:49:09
After looking through the conformance files, I decided to let changes in CRC, copyright, and emphasis through. Version 1.20 (http://omion.dyndns.org/mp3packer/mp3packer-1.20.rar) should now repack Menno's entire file.

I thought I had already turned off the requirement for CRC, but it looks like that was only between a frame determined to be an XING/LAME frame and the next frame. Oh well. It's off for all frames now.
Title: MP3 repacker
Post by: menno on 2008-05-07 15:40:33
Cool, thanks.
BTW: Did you ever check out the problem I reported with 256 and 320kbps CBR files? It seems to be the same problem LAME had when not using the ISO compliance flag. The windows system decoder does not decode such files.
Title: MP3 repacker
Post by: Omion on 2008-05-09 08:53:23
Cool, thanks.
BTW: Did you ever check out the problem I reported with 256 and 320kbps CBR files? It seems to be the same problem LAME had when not using the ISO compliance flag. The windows system decoder does not decode such files.

Sorry for the delay on that one. It looks like I just skipped it.

Try to use the "-r" option and see if that helps. That attempts to minimize the bit reservoir all the time. The only reason it's not on by default is that it requires more memory and slightly more processing time.

[edit]That is a really annoying limitation. It would take a whole lot of work to actually get this implemented. The MDB limit is based on the frame bitrate, which in mp3packer isn't decided on until the end, which looks like it would become a horrible mess. Therefore I must warn you: if the "-r" switch doesn't work then I doubt I'll come up with a fix for it...
Title: MP3 repacker
Post by: MooseCow on 2008-06-07 07:45:40
Arrgh!

I used the lastest version of this program along with Winmp3repacker to convert my collection to CBR......for some reason the files are still VBR according to Winamp and my CDJ. However, winmp3repacker still views them as CBR. I've even tried forcing them back to VBR and they're still viewed as CBR by Win Mp3 packer.

Any ideas of what to do next? Maybe use the program sans win mp3 repacker?

Btw, I used the "Auto Minimum bitrate" when converting.

EDIT: I've also tried to use "force" mode as well, and did manage to make one into VBR...but since it was VBR already, the only difference is that the program recognized it as VBR(as opposed tp thinking all CBR are VBR for some reason).
Title: MP3 repacker
Post by: [JAZ] on 2008-06-07 13:36:34
It is quite possible that mp3 repacker cannot change much the bitrate of those files, and ends up with an almost equal file, but adding the  vbr header.
Of couse, passing it back to cbr should have removed that, although i believe that if the file doesn't change, it keeps the original file, so that would explain the strange result.
Title: MP3 repacker
Post by: Ojay on 2008-06-09 18:09:50
Any ideas of what to do next? Maybe use the program sans win mp3 repacker?


Yes, use the command line program with the command "mp3packer -i <file.mp3>" Look for the minimum bitrate necessary for CBR, then use mp3packer with this bitrate: "mp3packer -b <bitrate> -R <file.mp3>"

Re-run mp3packer with the -i switch: "mp3packer -i <file-vbr.mp3>". Check it for being VBR or CBR, look for the bitrate distribution if you still get VBR.

If it is still VBR you need to start to experiment with the -b <bitrate> switch. Try "-b 320" first, (should always be CBR) then 256, 224, 192, 160, 128.... Always check it with an mp3packer run with the -i switch set.

Sometimes one gets crazy bitrate distributions like this one with 99.99% 128kbps and 0,01% 320kbps (which means that it is now a VBR mp3 file with almost exactly 128kbps). That usually points to at least one faulty and re-synced MP3 frame somewhere in the bitstream and means that your file was broken...

After that you should get a proper feeling what was happening (or was wrong), etc....
Title: MP3 repacker
Post by: MooseCow on 2008-06-14 22:31:00
Me being on windows vista wouldn't have anything to do with......

I tried some more files using Mp3 repacker.....same result....*sigh*...my poor CDJ.....

I don't get why I'm the only one having these problems....


Any ideas of what to do next? Maybe use the program sans win mp3 repacker?


Yes, use the command line program with the command "mp3packer -i <file.mp3>" Look for the minimum bitrate necessary for CBR, then use mp3packer with this bitrate: "mp3packer -b <bitrate> -R <file.mp3>"

Re-run mp3packer with the -i switch: "mp3packer -i <file-vbr.mp3>". Check it for being VBR or CBR, look for the bitrate distribution if you still get VBR.

If it is still VBR you need to start to experiment with the -b <bitrate> switch. Try "-b 320" first, (should always be CBR) then 256, 224, 192, 160, 128.... Always check it with an mp3packer run with the -i switch set.

Sometimes one gets crazy bitrate distributions like this one with 99.99% 128kbps and 0,01% 320kbps (which means that it is now a VBR mp3 file with almost exactly 128kbps). That usually points to at least one faulty and re-synced MP3 frame somewhere in the bitstream and means that your file was broken...

After that you should get a proper feeling what was happening (or was wrong), etc....



Thanks, only one problem?

How does one do these commands?

I've gotten mp3packer to run but I cant seem to get it to do anything to mp3s without it saying "syntax is wrong" or "error, no directory" etc.

*sigh* I'm considered just using ex-cd da to re-code the files, but I'd really love to get it working withou a loss in file quality.
Title: MP3 repacker
Post by: MooseCow on 2008-06-15 07:00:39
FIXED!

Had to set the minimum bitrate to 32, but they now play on the cdj-200!
Title: MP3 repacker
Post by: psyllium on 2008-07-18 05:55:13
FIXED!

Had to set the minimum bitrate to 32, but they now play on the cdj-200!


Sorry to hear you had trouble with WinMP3Packer... development on it has stagnated as I've been busy with work :/.

I'd recommend using the "3. Convert to CBR in place (force)" settings preset if you want *really* make sure the MP3s that it outputs are CBR (in other words, untick 'Auto' and select 'All' in the input types section)
Title: MP3 repacker
Post by: apoc_metal on 2008-09-16 20:39:10
Hey, here's a unixy binary of 1.20, compiled on osx 10.4.11 (intel)
I'll whip up a gui and post that in a bit.
http://alexyule.com/softwares/mp3packer.gz (http://alexyule.com/softwares/mp3packer.gz)

EDIT: Gui is now up, use it via drag-n-drop (multiple files supported). Each file will be processed, and the resulting output will go to the same folder with -vbr added to the song name.
i.e. 22 Acacia Ave.mp3 --> 22 Acacia Ave-vbr.mp3

Self-contained GUI is here: http://alexyule.com/softwares/mp3packerX_v1.20.zip (http://alexyule.com/softwares/mp3packerX_v1.20.zip)

Automator action to rename the vbr files (overwriting the originals) via drag-n-drop (you can just drag all the files and it will only rename the -vbr ones) is here: http://alexyule.com/softwares/mp3packer_renamer.zip (http://alexyule.com/softwares/mp3packer_renamer.zip)
Title: MP3 repacker
Post by: aand16 on 2008-09-19 00:42:18
Just found out about your tool  So sexy!
Title: MP3 repacker
Post by: th0mas on 2008-09-28 23:31:22
Hi everyone

I just registered to share that I built a native PPC mac OSX version of mp3packer.
I had to install ocaml from source to get it to work - both fink and macports builds failed to work as did the binary ocaml install.

I'm not sure of the dependencies on the binary so I included the entire source tree as it built for me, you can download my results here:

http://www.woopwoopwoop.com/mp3packer-bin-osx-ppc.zip (http://www.woopwoopwoop.com/mp3packer-bin-osx-ppc.zip)

Let me know if it doesn't work for you and I will try to help you get it working.

Cheers,
Tom
Title: MP3 repacker
Post by: Polar on 2008-11-16 10:24:04

97 MP3s, in: 437.67 MiB, out: 275.56 MiB, 37.0 % decrease in size!

The original files were all spoken word (Assimil language course MP3 CD) joint stereo 320 kbit/s CBR.  Stripped using MP3packer v1.20 along with WinMP3Packer v1.0.18, settings: -s -t -z.  Yielding equally great sounding VBR files of 201 kbit/s on average.

Great job, Omion and Psyllium!
Title: MP3 repacker
Post by: carpman on 2009-05-02 09:43:22
Anyone know if it's possible to run MP3 Repacker via foobar2000's converter dialog?
If so can someone let me know what the correct settings are.

Thanks in advance.

C.

EDIT: Peter's just said this is not possible so please ignore.
Thanks.
Title: MP3 repacker
Post by: Mix3dmessagez on 2009-06-23 17:55:18
is this only for CBR files?


i have lame V2 -vbr new files...and i have vista and when i open the command thing is dissapears too..is this only xp?
Title: MP3 repacker
Post by: PHOYO on 2009-06-23 21:31:08
is this only for CBR files?


i have lame V2 -vbr new files...and i have vista and when i open the command thing is dissapears too..is this only xp?


No, it will work with any MP3 out there, though there is no idea to use it with (LAME packed) VBR files because of the efficiency of (especially LAME) VBR model.

It's not only for XP. Open "Command prompt".
Title: MP3 repacker
Post by: helium on 2009-08-10 08:40:09
[EDIT] - My problem seems to be a corrupted mp3 file, completely unrelated to MP3 repacker.

Oh, and I almost forgot... thank you for the outstanding program. 
Title: MP3 repacker
Post by: helium on 2009-08-10 10:08:13
So, I take back my previous statement - of course, I don't mean the thankyou , but the one about a corrupted file. After testing some other tracks, I've discovered what appears to be an inconsistency in foobar2000's identification of the Codec Profile (Context Menu>Properties>Properties Tab) for LAME MP3s compressed by MP3 repacker. For example, both a 320kbps album repacked to ~300kbps VBR and a 192kbps album repacked to ~191 are identified by fbk2 as MP3 VBR V4, while another 320kbps album is identified as MP3 VBR V2.

Any thoughts?
Title: MP3 repacker
Post by: thesane on 2010-01-19 06:33:09
MP3Packer seems to change the encoder name in the tag to Xing.
I had a bunch of files encoded with FHG (CBR) [which was reflected in the tags], and after I used MP3Packer on them the encoder shows as Xing (VBR).
I wonder whether that is a feature or a bug?
Title: MP3 repacker
Post by: jaybeee on 2010-01-19 08:51:04
MP3Packer seems to change the encoder name in the tag to Xing.
I had a bunch of files encoded with FHG (CBR) [which was reflected in the tags], and after I used MP3Packer on them the encoder shows as Xing (VBR).
I wonder whether that is a feature or a bug?
Features:
* Writes valid LAME/XING header for proper VBR seeking
Title: MP3 repacker
Post by: hidn on 2010-03-11 16:44:31
thank you
Title: MP3 repacker
Post by: Omion on 2010-08-08 04:17:10
I'm still alive! 

I just had somebody send me a file which causes mp3packer to go really slowly. (not sure if he has an alias, and I don't want to drop people's real names on the internet) In response, 1.21 is out (http://omion.dyndns.org/mp3packer/mp3packer-1.21.rar).

Anyway, I made some of the algorithms a bit more efficient and less likely to take forever. The files should be exactly the same size and the frames should be in exactly the same places. The only difference between the files from 1.20 and 1.21 is the frame padding (which contains the version number).
Title: MP3 repacker
Post by: halb27 on 2010-08-08 20:31:49
Thank you, Omion. Nice to know that mp3packer is still actively being developed.
Title: MP3 repacker
Post by: Guillaume on 2010-08-16 13:19:16
It would be great if the new output files would have the same modification date and time as the originals: I like to see when I got the files/downloaded/ripped them.
Title: MP3 repacker
Post by: FoxWolfie on 2010-08-29 13:11:42
In response, 1.21 is out (http://omion.dyndns.org/mp3packer/mp3packer-1.21.rar).


Hi.  I've been successfully using mp3packer for a couple years, and am currently on version 1.20.  It's been a very handy program for repairing damaged files and stripping non-audio data.  Hoping to see an improvement in speed for the -z option, I downloaded version 1.21.  However, when I attempt to run the .exe, it simply says,

(Sys) This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
"L:\Mp3Packer\mp3packer.exe"

I tried various command lines that have always worked in previous versions, as well as mp3packer with no parameters. All result in the same error on two different systems - one a Win XP sp3 system, and the other a Win 2000 system.  Any suggestions for getting this latest version to run?
Title: MP3 repacker
Post by: LordWarlock on 2010-08-29 16:07:53
Install c++ 2008 redistributable (http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en)
Title: MP3 repacker
Post by: FoxWolfie on 2010-08-29 22:56:39
Install c++ 2008 redistributable (http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en)


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.
Title: MP3 repacker
Post by: FoxWolfie on 2010-08-29 23:03:45
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.
Title: MP3 repacker
Post by: Guillaume on 2010-08-29 23:47:10
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?
Title: MP3 repacker
Post by: jimmanningjr on 2010-08-31 02:55:33
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 (http://vcardenasblog.blogspot.com/2008/09/album-art-extracter-for-rockbox.html)
You can run it on any folder...just sayin'
Title: MP3 repacker
Post by: jimmanningjr on 2010-08-31 03:07:25
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 (http://vcardenasblog.blogspot.com/2008/09/album-art-extracter-for-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???
Title: MP3 repacker
Post by: Guillaume on 2010-08-31 10:12:12
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 (http://vcardenasblog.blogspot.com/2008/09/album-art-extracter-for-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.
Title: MP3 repacker
Post by: jimmanningjr on 2010-08-31 22:47:17
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 (http://vcardenasblog.blogspot.com/2008/09/album-art-extracter-for-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.
Title: MP3 repacker
Post by: FoxWolfie on 2010-09-01 07:39:42
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.
Title: MP3 repacker
Post by: Northpack on 2010-09-01 10:00:03
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 (http://www.mp3tag.de/). 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.
Title: MP3 repacker
Post by: Guillaume on 2010-09-01 18:47:58
@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!
Title: MP3 repacker
Post by: jimmanningjr on 2010-09-01 23:11:06
@ 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 !!!
Title: MP3 repacker
Post by: FoxWolfie on 2010-09-02 00:38:34
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 (http://www.mp3tag.de/). 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.
Title: MP3 repacker
Post by: Northpack on 2010-09-02 09:35:38
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.
Title: MP3 repacker
Post by: Antonski on 2010-09-02 14:31:38
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.
Title: MP3 repacker
Post by: FoxWolfie on 2010-09-02 17:27:04
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.
Title: MP3 repacker
Post by: greynol on 2010-09-02 17:38:01
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.
Title: MP3 repacker
Post by: deranger on 2010-09-14 13:51:18
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 ???
Title: MP3 repacker
Post by: Omion on 2010-09-15 04:36:08
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.
Title: MP3 repacker
Post by: deranger on 2010-09-15 14:27:56
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
Title: MP3 repacker
Post by: Omion on 2010-09-17 03:56:20
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
Title: MP3 repacker
Post by: bsdaiwa on 2011-01-05 14:19:34
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
Title: MP3 repacker
Post by: kode54 on 2011-01-29 16:57:14
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.
Title: MP3 repacker
Post by: mjb2006 on 2011-01-29 20:12:50
Does anyone have a mirror of version 1.21?

Here: mp3packer-1.21.rar - 0.21MB (http://www.zshare.net/download/858843190d2bff10/) (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.
Title: MP3 repacker
Post by: Jens Rex on 2011-01-29 21:56:23
Here: mp3packer-1.21.rar - 0.21MB (http://www.zshare.net/download/858843190d2bff10/) (at zShare)
File is broken.

I've got 1.20 here. Uploaded v1.21 instead.

http://jensrex.net/bin/mp3packer-1.21.zip (http://jensrex.net/bin/mp3packer.exe)
Title: MP3 repacker
Post by: Martin F. on 2011-01-29 22:15:09
http://wikifortio.com/827848/mp3packer-1.21.zip (http://wikifortio.com/827848/mp3packer-1.21.zip)
Title: MP3 repacker
Post by: benski on 2011-01-29 22:46:38
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


Thanks for the report.  I fixed the issue with the frame approximation. 

When there is no Xing, LAME or VBRI header present, it's totally a guess, as you had suspected.  Luckily, VBR mp3 files without one of these headers is relatively rare.

And, yes, it's reporting ABR because that's how it was defined in the LAME info tag.  Ideally MP3 repacker could change the encoding type bits in the LAME header to reflect the changes.  I assume it already rebuilds the seektable.

Also, yes for clarification, the LAME header isn't counted in the frame count nor does it count in the "Header found at" reporting.
Title: MP3 repacker
Post by: mjb2006 on 2011-01-30 03:51:49
File is broken.


Ugh, sorry. It showed the right size on zShare, but when I tried downloading it, only half of it transferred. I have removed the file. I assume the .zip posted by Martin F. is OK?
Title: MP3 repacker
Post by: а.п.т. on 2011-01-31 07:49:39
...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.
Probably mp3file is not registered on your system.
I've checked mine, it seems that wmplayer has registered that type, so I've just added a new shell extension, see below:

Code: [Select]
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\mp3file]
"PreferExecuteOnMismatch"=dword:00000001
"EditFlags"=hex:00,00,01,00
@="MP3 Format Sound"
"FriendlyTypeName"="@C:\\WINDOWS\\inf\\unregmp2.exe,-9925"

[HKEY_CLASSES_ROOT\mp3file\DefaultIcon]
@="C:\\PROGRA~1\\WINDOW~2\\wmplayer.exe,-120"

[HKEY_CLASSES_ROOT\mp3file\shell]
@="play"

[HKEY_CLASSES_ROOT\mp3file\shell\&Repack_with_mp3packer]
@="&Repack with mp3packer"

[HKEY_CLASSES_ROOT\mp3file\shell\&Repack_with_mp3packer\command]
@="D:\\Util\\mp3repacker\\mp3packer.exe -z -u --nice 1 -a \"-old\" \"%1\""

[HKEY_CLASSES_ROOT\mp3file\shell\&Repack_with_mp3packer\ddeexec]

[HKEY_CLASSES_ROOT\mp3file\shell\&Repack_with_mp3packer\ddeexec\Application]
@="mp3packer"

[HKEY_CLASSES_ROOT\mp3file\shell\&Repack_with_mp3packer\ddeexec\Topic]
@="System"

[HKEY_CLASSES_ROOT\mp3file\shell\open]
@="&Open"
"LegacyDisable"=""

[HKEY_CLASSES_ROOT\mp3file\shell\open\command]
@="\"C:\\Program Files\\Windows Media Player\\wmplayer.exe\" /prefetch:6 /Open \"%L\""

[HKEY_CLASSES_ROOT\mp3file\shell\open\DropTarget]
"CLSID"="{CE3FB1D1-02AE-4a5f-A6E9-D9F1B4073E6C}"

[HKEY_CLASSES_ROOT\mp3file\shell\play]
"MUIVerb"=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,\
  6f,00,74,00,25,00,5c,00,69,00,6e,00,66,00,5c,00,75,00,6e,00,72,00,65,00,67,\
  00,6d,00,70,00,32,00,2e,00,65,00,78,00,65,00,2c,00,2d,00,39,00,39,00,39,00,\
  31,00,00,00
@="&Play"
"LegacyDisable"=""

[HKEY_CLASSES_ROOT\mp3file\shell\play\command]
@="\"C:\\Program Files\\Windows Media Player\\wmplayer.exe\" /prefetch:6 /Play \"%L\""

Hope this helps...
Title: MP3 repacker
Post by: Code on 2011-04-05 23:12:06
Hey, here's a unixy binary of 1.20, compiled on osx 10.4.11 (intel)
I'll whip up a gui and post that in a bit.
http://alexyule.com/softwares/mp3packer.gz (http://alexyule.com/softwares/mp3packer.gz)

EDIT: Gui is now up, use it via drag-n-drop (multiple files supported). Each file will be processed, and the resulting output will go to the same folder with -vbr added to the song name.
i.e. 22 Acacia Ave.mp3 --> 22 Acacia Ave-vbr.mp3

Self-contained GUI is here: http://alexyule.com/softwares/mp3packerX_v1.20.zip (http://alexyule.com/softwares/mp3packerX_v1.20.zip)

Automator action to rename the vbr files (overwriting the originals) via drag-n-drop (you can just drag all the files and it will only rename the -vbr ones) is here: http://alexyule.com/softwares/mp3packer_renamer.zip (http://alexyule.com/softwares/mp3packer_renamer.zip)



Hey Apoc_Metal (or anyone else who can help!)

I have been trying to get version 1.2 of the mp3packer program to run on my Mac but haven't had any luck so far.

I've been using Terminal to try to launch it - but it gave me a message saying "no application knows how to open Desktop/mp3packer"

after that I tried adding the extention .app to the filename, but then I got a error code in the Terminal window after I tried to open it again.

I'm not very knowledgeable about working with the Terminal window... any suggestions would be appreciated.
Would be especially interested in learning how to get the GUI working, once the mp3packer itself is running of course !


My Mac is a Duo core Intel running OS X 10.5.8 by the way...


Title: MP3 repacker
Post by: stereotype on 2011-04-11 22:09:08
Forgive me if this has been discussed before in this thread as I didn't feel like going through 20 pages to find out...

I was running mp3repacker on the mp3 soundtrack of a TV series, and I just found out by accident that apparently mp3packer writes a header like "mp3packer1.21-229" several times into the packed mp3.
Sorry if this sounds stingy but, isn't this wasted space?
I mean, I thought the whole point of mp3packer was to try to reduce the stream by every byte possible... Or am I missing something?
Presuming it writes that for every frame, that's 17 bytes per frame.
The soundtrack in question had 106,000 frames, and doing the math, that's like 1.8 MBs
It might not sound like much, but the soundtrack is a low bitrate mono mp3 weighing only 10MB.
Which means 18% are wasted bits...

Now I'm not sure mp3packer really writes that for every frame, but if it does, it seems like a lot of wasted bits...
Is this correct, or did I get it wrong somewhere?
Title: MP3 repacker
Post by: apoc_metal on 2011-05-16 09:52:01
Hey, here's a unixy binary of 1.20, compiled on osx 10.4.11 (intel)
I'll whip up a gui and post that in a bit.
http://alexyule.com/softwares/mp3packer.gz (http://alexyule.com/softwares/mp3packer.gz)

EDIT: Gui is now up, use it via drag-n-drop (multiple files supported). Each file will be processed, and the resulting output will go to the same folder with -vbr added to the song name.
i.e. 22 Acacia Ave.mp3 --> 22 Acacia Ave-vbr.mp3

Self-contained GUI is here: http://alexyule.com/softwares/mp3packerX_v1.20.zip (http://alexyule.com/softwares/mp3packerX_v1.20.zip)

Automator action to rename the vbr files (overwriting the originals) via drag-n-drop (you can just drag all the files and it will only rename the -vbr ones) is here: http://alexyule.com/softwares/mp3packer_renamer.zip (http://alexyule.com/softwares/mp3packer_renamer.zip)



Hey Apoc_Metal (or anyone else who can help!)

I have been trying to get version 1.2 of the mp3packer program to run on my Mac but haven't had any luck so far.

I've been using Terminal to try to launch it - but it gave me a message saying "no application knows how to open Desktop/mp3packer"

after that I tried adding the extention .app to the filename, but then I got a error code in the Terminal window after I tried to open it again.

I'm not very knowledgeable about working with the Terminal window... any suggestions would be appreciated.
Would be especially interested in learning how to get the GUI working, once the mp3packer itself is running of course !


My Mac is a Duo core Intel running OS X 10.5.8 by the way...

Hm, seems that gzipped version of the binary is messed up... but the osx front-end has a working version stored inside the application package, so it should work just fine! Anyone who wants the binaries can grab them here http://omion.dyndns.org/mp3packer/ (http://omion.dyndns.org/mp3packer/) there's an updated version 1.21 that I haven't tried since I can't get it to compile (I have no idea what I'm doing ) -- anyone know how to modify the makefile to get it to compile on OSX? Seems it gets tripped up by c_part? EDIT: Nevermind, got it to work!
Title: MP3 repacker
Post by: apoc_metal on 2011-05-16 20:37:59
Alrighty, I've updated my rudimentary OSX GUI with a 1.21 binary.
USAGE: Drag a bunch of mp3's onto the app, then wait. Then run the automator action to rename the files or do it by hand...
Currently the app does NOT handle pathnames with single quotes in them.
All files can be found here: http://alexyule.com/softwares (http://alexyule.com/softwares)
I've also posted the binary itself, compiled on an intel mac running OSX, not sure what other platforms it'll run on...
Title: MP3 repacker
Post by: alexeysp on 2011-05-18 16:03:03
I was running mp3repacker on the mp3 soundtrack of a TV series, and I just found out by accident that apparently mp3packer writes a header like "mp3packer1.21-229" several times into the packed mp3.
Sorry if this sounds stingy but, isn't this wasted space?


A late reply is better than no reply.

This is not a "header", but the "filler". The mp3 standard defines fixed set of allowed bitrates on a per-frame basis. Particularly, the minimum allowed bitrate is 32 kilobits per second - even if the stream can be compressed further, the relevant frame still has to be padded with extra bits to fulfill the minimum allowed bitrate requirement. This requirement of the standard imposes the minimum (as well as maximum) allowed frame size restriction depending on the encoding process history and current state. In other words, some frames can not get smaller than certain size, even when there is no audio data to encode into that space. The payload in such frames can be filled with arbitrary bits; mp3repacker fills it with the version info string. So there is no waste of space, mp3repacker always produces the most compact specification-compliant stream possible.
Title: MP3 repacker
Post by: skexu on 2011-05-18 16:26:29
Quote
Particularly, the minimum allowed bitrate is 32 kilobits per second - even if the stream can be compressed further, the relevant frame still has to be padded with extra bits to fulfill the minimum allowed bitrate requirement.


Actually mpeg-2 layer 3 defines minimal bitrate of 8 kbps and IIRC 8kbps files are smaller than 32 kbps, am I wrong?
Title: MP3 repacker
Post by: lvqcl on 2011-05-18 17:11:35
It's not possible to losslessly convert MPEG-1 layer 3 to MPEG-2 layer 3.
Title: MP3 repacker
Post by: moozooh on 2011-05-18 18:47:35
Can those bits be used for bit reservoir, or is it not possible?
Title: MP3 repacker
Post by: alexeysp on 2011-05-19 15:10:09
Can those bits be used for bit reservoir, or is it not possible?


They are used when possible. The filler is inserted only when encoder (or repacker) runs out of useful bits, e.g. with the long sequences of silent frames.
Title: MP3 repacker
Post by: Omion on 2011-06-27 07:45:37
I'm not quite dead! 

Someone traversed the internet to send me some problem files, so in response I came out with version 1.22 (http://omion.dyndns.org/mp3packer/mp3packer-1.22.rar).
I also decided to post a mirror (http://dl.dropbox.com/u/5833814/mp3packer/mp3packer-1.22.rar) on my Dropbox account, in case my home server gives up the ghost again. The source is here (http://omion.dyndns.org/mp3packer/mp3packer-1.22_src.zip) (mirror (http://dl.dropbox.com/u/5833814/mp3packer/mp3packer-1.22_src.zip)).

The biggest problem was that one of my string-initialization routines would cause an out-of-bounds access with a very specific type of corrupted frame. I also discovered a case when the -z switch would not process the input properly, causing a small number of corrupted frames to not be processed.

The program now shows the number of decompression errors in the bitstream that the -z switch has encountered. I had the code in there for years, but for some reason I never did anything with it.


The processing of corrupted frames by the -z switch means that there may be some changes to the audio on those frames. In my experience, the changes are limited to the 1 or 2 highest-frequency samples encoded. These changes will ONLY ever occur on corrupted or otherwise invalid frames, not valid ones. They will be accompanied by a "decompression error" warning.


P.S. I'll change the main post as soon as I can get permission. (looks like someone changed the forum rules while I was gone!)
[edit]Woo! I can edit now! Main post updated.
Title: MP3 repacker
Post by: hidn on 2011-07-14 15:51:17
thank you!
possible icl version?
Title: MP3 repacker
Post by: lvqcl on 2011-07-14 16:46:32
possible icl version?

Since when ICL was able to compile OCaml? 
Title: MP3 repacker
Post by: hidn on 2011-07-14 17:04:02
I do not know 
Title: MP3 repacker
Post by: Omion on 2011-07-14 22:43:28
thank you!
possible icl version?

No ICL version, unfortunately. As lvqcl implied, there is no way to compile OCaml with ICL.

I am trying to put together a multi-threaded(*) version for batch processing, which should help with today's multi-core CPUs (it wasn't as much of an issue when I started this in 2004  ) It's sort of a background project now, but I should be able to get it done eventually.


(*) Well, technically OCaml can't really speed up things when multi-threading, so I'm really trying to get multiple processes running simultaneously. It's a bit trickier than multi-threading, so I'm running a lot of tests before releasing it.
Title: MP3 repacker
Post by: Antonski on 2011-07-15 07:48:03
(*) Well, technically OCaml can't really speed up things when multi-threading, so I'm really trying to get multiple processes running simultaneously. It's a bit trickier than multi-threading, so I'm running a lot of tests before releasing it.


I think running parallel processes in Perl is much easier than multi-threading, but I guess you don't want to go back to Perl, right?
Title: MP3 repacker
Post by: hidn on 2011-07-15 12:07:50
Thanks for the continued development
Title: MP3 repacker
Post by: Omion on 2011-07-16 04:17:32
(*) Well, technically OCaml can't really speed up things when multi-threading, so I'm really trying to get multiple processes running simultaneously. It's a bit trickier than multi-threading, so I'm running a lot of tests before releasing it.


I think running parallel processes in Perl is much easier than multi-threading, but I guess you don't want to go back to Perl, right?

Yeah, Perl would be terribly slow, especially for the -z stuff. And I'm much more used to OCaml now than Perl.
Title: MP3 repacker
Post by: no404error on 2011-08-13 00:08:43
mp3packer 1.22-230

Fatal error: exception Invalid_argument("String.sub")

Example mp3 - http://www.multiupload.com/IBM89OEUQ1 (http://www.multiupload.com/IBM89OEUQ1)
Title: MP3 repacker
Post by: Omion on 2011-08-15 02:24:02
mp3packer 1.22-230

Fatal error: exception Invalid_argument("String.sub")

Example mp3 - http://www.multiupload.com/IBM89OEUQ1 (http://www.multiupload.com/IBM89OEUQ1)

Thanks for the report. I just released 1.23 to fix it. (download (http://omion.dyndns.org/mp3packer/mp3packer-1.23.rar)) (mirror (http://dl.dropbox.com/u/5833814/mp3packer/mp3packer-1.23.rar))

I'm sure I've fixed this bug about 5 times before, but it keeps coming back in slightly different ways. Hopefully it stays fixed this time.
Title: MP3 repacker
Post by: no404error on 2011-08-15 08:10:50
Quote
Thanks for the report. I just released 1.23 to fix it. (download (http://omion.dyndns.org/mp3packer/mp3packer-1.23.rar)) (mirror (http://dl.dropbox.com/u/5833814/mp3packer/mp3packer-1.23.rar))

I'm sure I've fixed this bug about 5 times before, but it keeps coming back in slightly different ways. Hopefully it stays fixed this time.

Thanks for the fix  1.23 works perfect on my problem files.
Title: MP3 repacker
Post by: stereotype on 2011-10-20 04:33:34
I'm trying to compile it under Fedora 15 64-bit, and I'm getting the following error:

Code: [Select]
$ make OBJ_EXT=.o
ocamlopt -c crc.ml
ocamlopt list2.mli
ocamlopt -c list2.ml
ocamlopt expandarray.mli
ocamlopt -c expandarray.ml
ocamlopt c_part.c
ocamlopt -c mp3types.ml
ocamlopt -c pack.ml
ocamlopt -c mp3read.ml
File "mp3read.ml", line 172, characters 7-18:
Warning 26: unused variable return_none.
File "mp3read.ml", line 76, characters 35-40:
Warning 16: this optional argument cannot be erased.
ocamlopt -c mp3write.ml
ocamlopt -c mp3info.ml
ocamlopt -c mp3types.cmx pack.cmx mp3framehuffman.ml
ocamlopt -c mp3types.cmx pack.cmx mp3framehuffman.cmx mp3frameutils.ml
ocamlopt -c mp3queue.ml
File "mp3queue.ml", line 312, characters 6-18:
Warning 26: unused variable bitrate_list.
File "mp3queue.ml", line 361, characters 5-18:
Warning 26: unused variable print_bitrate.
File "mp3queue.ml", line 347, characters 5-26:
Warning 26: unused variable update_side_reservoir.
File "mp3queue.ml", line 115, characters 5-13:
Warning 26: unused variable debug_in.
File "mp3queue.ml", line 420, characters 28-2840:
Warning 8: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
{side_bits=[|  |]}
File "mp3queue.ml", line 479, characters 18-2324:
Warning 8: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
{side_bits=[|  |]}
File "mp3queue.ml", line 538, characters 24-1361:
Warning 8: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
{side_bits=[|  |]}
File "mp3queue.ml", line 577, characters 14-1514:
Warning 8: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
{side_bits=[|  |]}
ocamlopt -c multiproc.ml
File "multiproc.ml", line 163, characters 3-65:
Warning 5: this function application is partial,
maybe some arguments are missing.
File "multiproc.ml", line 219, characters 3-65:
Warning 5: this function application is partial,
maybe some arguments are missing.
File "multiproc.ml", line 359, characters 5-88:
Warning 10: this expression should have type unit.
ocamlopt -o mp3packer.exe unix.cmxa str.cmxa crc.cmx list2.cmx expandarray.cmx c_part.o mp3types.cmx pack.cmx mp3read.cmx mp3write.cmx mp3info.cmx mp3framehuffman.cmx mp3frameutils.cmx mp3queue.cmx multiproc.cmx mp3packer.ml
File "mp3packer.ml", line 331, characters 8-14:
Warning 26: unused variable errors.
File "mp3packer.ml", line 335, characters 8-14:
Warning 26: unused variable errors.
ocamlopt -o mp3reader.exe unix.cmxa crc.cmx list2.cmx c_part.o mp3types.cmx pack.cmx mp3read.cmx mp3reader.ml
File "mp3reader.ml", line 1, characters 0-1:
Error: No implementations provided for the following modules:
        Str referenced from mp3types.cmx
make: *** [mp3reader] Error 2
Any ideas?
Title: MP3 repacker
Post by: Omion on 2011-10-20 07:01:54
@stereotype:

It looks like I haven't updated the mp3reader dependencies in the makefile. You can fix it by adding "str.cmxa" after "unix.cmxa" in the mp3reader line of the makefile:
Code: [Select]
<TAB>ocamlopt -o mp3reader$(EXE_EXT) unix.cmxa str.cmxa crc.cmx list2.cmx c_part$(OBJ_EXT) mp3types.cmx pack.cmx mp3read.cmx mp3reader.ml

(the <TAB> at the beginning should be an actual tab)

However, you probably don't need mp3reader at all. It's just a program to output MP3 statistics in a Mathematica-style format. Run this to just make mp3packer:
Code: [Select]
make mp3packer OBJ_EXT=.o

Title: MP3 repacker
Post by: Hallie08 on 2011-11-02 11:47:34
I note you have to know that mp3packer does not support mp3-freeformat(which exceeds the 320kbps) and mp3pro data..

And as you conclude there a tool for mp3,ogg, but still nothing for AAC and I think it would in the FAR future .. Many a tool to transcode AAC into AAC+ or HE-AAC
Title: MP3 repacker
Post by: Porcus on 2012-01-21 15:38:28
Wishlist items: Unicode file name support, and after-write-verify.

(Playing a bit around with this certainly exposes Windows Explorer's failure to display VBR bitrates correctly :-o )
Title: MP3 repacker
Post by: Porcus on 2012-01-21 18:46:40
and after-write-verify.


(Is the outfile supposed to have identical length as the original? One of my test files did in fact not.)
Title: MP3 repacker
Post by: Omion on 2012-01-30 21:06:10
and after-write-verify.


(Is the outfile supposed to have identical length as the original? One of my test files did in fact not.)

Sorry about the wait for the reply.

The output file should be the same length as the input file, but errors in the input file may make that not be the case. It's also sometimes because mp3packer adds an XING/LAME tag, which can show up as an extra music frame by some programs. Is the resultant file longer or shorter than the input?

About the other requests:
write-after-verify should work already. Using "--keep-bad in --keep-ok out" will remove the old files if everything was OK, but will not save the new file if there was an error. Was there something else you wanted the program to do?

OCaml does not natively support Unicode, but I've added my own wrappers for Windows Unicode functions in the past. I haven't added it to mp3packer since it is OS specific, but I suppose I can set it as a conditional compilation. I'll see how easy it would be to shoehorn it in to this program when I get the time.
Title: MP3 repacker
Post by: Porcus on 2012-01-30 22:13:03
The output file should be the same length as the input file, but errors in the input file may make that not be the case. It's also sometimes because mp3packer adds an XING/LAME tag, which can show up as an extra music frame by some programs. Is the resultant file longer or shorter than the input?


On the fairly few issues encountered, output is some .02 to .03 seconds longer. These are files which are OK according to foobar2000's 'Verify integrity' function. (No wrong length reported, no decoding error.) BTW, the test for differences was also done with fb2k's 'Bit-compare' function.


"--keep-bad in --keep-ok out"


*blush* Should have thought of that combination.


A bit of playing around back and forth with -z: it might save a couple of percents on average – people do change lossless codecs over less of a reduction. But every now and then, a 320 CBR file proves its inefficiency – there was one album which was reduced by a whopping 15 percent. (No, not one of those with half an hour silence before a hidden bonus track, and yes, I checked the outfile was bit-identical). I have actually tried a few settings to try to provoke forth anything remotely close to this with a recent LAME, at no 'success'.

Had I just had a completely full 20 GB portable player as my a backup, the space saved would certainly be worth the effort. Now I'm not constrained on space (and I have a bit of files with unsupported characters), but it is still fun to play around with.
Title: MP3 repacker
Post by: Porcus on 2012-01-31 13:52:31
The following is however curious (at least to me). Used "--keep-bad in --keep-ok out" on a few folders, and got only two files differing, reported as follows:


Differences found: 1 sample(s), starting at 8.5073469 second(s), peak: 0.0000000 at 8.5073469 second(s), 2ch

Differences found: 2 sample(s), starting at 162.4575964 second(s), peak: 0.0000000 at 284.4125624 second(s), 1ch


(Re-did the exercise just to be sure.)


Maybe a Q for the foobar2000 forum?
Title: MP3 repacker
Post by: Omion on 2012-02-17 05:40:56
1.24 is out! Get it here (http://omion.dyndns.org/mp3packer/mp3packer-1.24.7z) (mirror (http://dl.dropbox.com/u/5833814/mp3packer/mp3packer-1.24.7z))

Only minor bug fixes this time. Valid input files will compress the same as before. The only differences are:
Lots of warnings when -z gives an error (it was not always reported in the past)
Slightly more strict with certain types of overflows

In conclusion: more console spam! 

Oh, and the download is a 7zip archive this time. I lost WinRAR somewhere when I re-installed Windows, and I didn't bother to find it since I had already installed 7zip.
Title: MP3 repacker
Post by: Omion on 2012-02-25 07:25:35
1.25 is now out. Get it here (http://omion.dyndns.org/mp3packer/mp3packer-1.25.7z).
2 releases in 8 days! I'm on a roll! 

The major enhancement is Unicode support at last! It should be able to handle Unicode names in both files and directories, although it may not display them correctly due to command-line limitations.

I also made a few minor changes to the re-synchronization code, which should be faster for files with large amounts of non-MP3 data. One limitation is that now it will probably no longer support files larger than 1GB (unless you build a 64-bit binary). Actually, now that I think about it, that may have always been a limitation... I've never tested files that big.
Title: MP3 repacker
Post by: Raimu on 2012-07-02 12:47:41
@Omion:

I think you may've introduced something problematic into your latest version of mp3packer -- when used in a command prompt window on my Windows 7 x64, the command prompt goes nuts after having run mp3packer once. The cmd starts spouting out "The system cannot write to the specified device." errors and closing the window randomly. Commands stop working and the command prompt crashes out.

I have checked versions 1.20 and after that 1.24 to rule out a long-term incompatibility. It's only the 1.25 that messes up my W7/x64 comprompt.
Title: MP3 repacker
Post by: Omion on 2012-07-02 19:55:53
@Omion:

I think you may've introduced something problematic into your latest version of mp3packer -- when used in a command prompt window on my Windows 7 x64, the command prompt goes nuts after having run mp3packer once. The cmd starts spouting out "The system cannot write to the specified device." errors and closing the window randomly. Commands stop working and the command prompt crashes out.

I have checked versions 1.20 and after that 1.24 to rule out a long-term incompatibility. It's only the 1.25 that messes up my W7/x64 comprompt.

It was almost certainly due to the Unicode stuff I added. It's rather impressive that the program crashes the entire command prompt 
Now to see how to fix it:

Does this happen on every file you run?
Do you have anything on the system that uses non-ASCII characters?
What is the output of the "chcp" command?

Also, if you could post the exact command you typed in and the response it would help.

Thanks.
Title: MP3 repacker
Post by: Raimu on 2012-07-03 00:37:36
Quote
> Now to see how to fix it:
> Does this happen on every file you run?

It happens every time I run mp3packer in cmd, even if I don't define any parameters.

Quote
> Do you have anything on the system that uses non-ASCII characters?

My Win language is English, but I type in a Finnish character setting. Other than that, I don't have any foreign character input methods in use - for example Cyrillic or Asian.

Quote
What is the output of the "chcp" command?

Code: [Select]
"Active code page: 850"


Quote
Also, if you could post the exact command you typed in and the response it would help.

Code: [Select]
E:\>mp3packer -help

MP3 Packer version 1.25-237
Copyright 2006-2008 Reed "Omion" Wilson
[...]
  -help          Display this list of options
  --help         Display this list of options

E:\>dir
The system cannot write to the specified device.

The system cannot write to the specified device.

The system cannot write to the specified device.

The system cannot write to the specified device.
Title: MP3 repacker
Post by: Omion on 2012-07-03 02:15:08
It happens every time I run mp3packer in cmd, even if I don't define any parameters.

Ah! So it does this even when no processing takes place. That really narrows it down.
I can't seem to reproduce the problem on my computer, but I'm pretty sure I know where it is.
Try this (https://dl.dropbox.com/u/5833814/7EA82300FD287C20C98211CD6641F563-mp3packertemp/mp3packer-nounioutput.zip) version of the program. If that fixes it, I'll make it official within a few days.
Title: MP3 repacker
Post by: Raimu on 2012-07-03 12:33:04
Sure thing, this one works.
Title: MP3 repacker
Post by: Porcus on 2012-07-04 14:23:53
A bit of playing around back and forth with -z:
[...]
every now and then, a 320 CBR file proves its inefficiency – there was one album which was reduced by a whopping 15 percent. (No, not one of those with half an hour silence before a hidden bonus track, and yes, I checked the outfile was bit-identical). I have actually tried a few settings to try to provoke forth anything remotely close to this with a recent LAME, at no 'success'.


More 320 files tested, and a reduction of 7 percent seems quite common, bringing the bitrate below the 300 mark. I acquired a few from services like http://www.scionav.com/index (http://www.scionav.com/index) (in exchange of my mail address). It seems that iTunes is a widespread encoder these days (by tag ... EncSpot reports as FhG), and well, you should expect 7 percent reduction by -z'ing these 320's.
Which isn't necessarily to say that 320 is itself inefficient on space – it could very well be that even professionals don't bother to use the CPU-intensive 'better' options? (EncSpot reports something on the psymodel, but I have no idea of what it means.)


I also tested decoding speed, to see if heavier packing penalizes the CPU on playback. Small difference: 129.5 x realtime for 320 CBR, 130.2 for the -z'ed 298 VBR's – this on a computer which decodes FLAC at 180 to 200 times realtime (good job, Coalson). Tool used: foobar2000's decoding speed test, all from RAM.
Title: MP3 repacker
Post by: Guillaume on 2012-07-09 11:13:44
This could be related to something else (I thought of something related to my new SSD, but it also happens on an external HDD) but I ONLY experience this while using mp3packer, so bear with me plz:

When using --keep-ok "out" at times mp3packer just quits with the error message that the original file could not be removed.

Code: [Select]
Repacking successful; deleting backup
Fatal error: exception Sys_error("Adam Green - (2002) Adam Green/01 - Apples, I'
m Home_org.mp3: Permission denied")


Via WinMp3Packer using v1.25, I get the following error every so often:

Code: [Select]
System.UnauthorizedAccessException: Access to the path 'E:\Music\D\Das Pop - (2003) The Human Thing\09 - The Machine.mp3' is denied.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileInfo.Delete()
   at WinMP3Packer.MainForm.KillFile(FileInfo fi)
   at WinMP3Packer.MainForm.KillFile(String fileName)
   at WinMP3Packer.MainForm.ProcessFile(PackerQueueItem item)Finished processing file.


I do not use any resident antivirus software or any other program that could prevent mp3packer from accessing the file...
Title: MP3 repacker
Post by: Porcus on 2012-07-09 13:25:13
Code: [Select]
Repacking successful; deleting backup
Fatal error: exception Sys_error("Adam Green - (2002) Adam Green/01 - Apples, I'
m Home_org.mp3: Permission denied")


There is a linebreak here. Does anything change if you remove the apostrophe from the filename?
Title: MP3 repacker
Post by: Guillaume on 2012-07-09 13:35:41
No, it also happens on files without an apostrophe or any other special character.
Title: MP3 repacker
Post by: Guillaume on 2012-07-10 14:04:34
As I expected there are more problems with a delayed file handle closing on Windows 7 x64 to be found on various fora, not specific to mp3packer, but it does seem mp3packer is somehow affected by it. As a result, when attempting to remove the old file, it still looks like mp3packer is using it. I read something about compatibility modes, so now I'm trying to run mp3packer.exe in Vista SP2 compatibility mode. No problems so far, but only with a small sample set.
Title: MP3 repacker
Post by: robert on 2012-07-10 15:14:00
Sounds like the typical pitfalls of RAII pattern, (http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization) when a garbage collector is involved. But, neither do I know ocaml, nor the mp3packer source code. So it's only a guess.
Title: MP3 repacker
Post by: Omion on 2012-07-11 19:05:55
As I expected there are more problems with a delayed file handle closing on Windows 7 x64 to be found on various fora, not specific to mp3packer, but it does seem mp3packer is somehow affected by it. As a result, when attempting to remove the old file, it still looks like mp3packer is using it. I read something about compatibility modes, so now I'm trying to run mp3packer.exe in Vista SP2 compatibility mode. No problems so far, but only with a small sample set.

I think I fixed it in 1.26 (http://omion.dyndns.org/mp3packer/mp3packer-1.26.7z). Give that a shot.

I didn't really know what the problem could have been until I saw Robert's post:

Sounds like the typical pitfalls of RAII pattern, (http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization) when a garbage collector is involved. But, neither do I know ocaml, nor the mp3packer source code. So it's only a guess.

OCaml doesn't garbage collect filehandles for that exact reason. However the clueless programmer who wrote the memory-mapping module (me ) relied on the garbage collector to clean up the memory map. If the map doesn't get closed, the file handle won't get closed and the file can't be deleted. So that was fixed.

I did some simple tests and it hasn't complained about permissions again. I also fixed a few issues with Unicode support (the fix for Raimu's problem is included, and renaming / deleting Unicode files should work)
Title: MP3 repacker
Post by: Guillaume on 2012-07-12 12:02:12
Thank you so much for the quick fix, Omion! I'm currently transferring my music collection to another drive, so I thought it would be the best time to be (even more) strict about the tags and fixing them, and packing them afterwards.

One more question, undoubtedly posed before (sorry): is there any way to make MP3packer preserve the original file's modification date & time?
These dates are nice to preserve, because those indicate the times around which I discovered the bands/albums.
Title: MP3 repacker
Post by: Raimu on 2012-07-12 15:44:18
Thank you, Omion!
Title: MP3 repacker
Post by: Omion on 2012-07-12 16:09:57
One more question, undoubtedly posed before (sorry): is there any way to make MP3packer preserve the original file's modification date & time?
These dates are nice to preserve, because those indicate the times around which I discovered the bands/albums.

There's no way to do that yet. I had resisted adding that support since the output file was actually a new file so it should have a new creation/modification date. However, if you use the -u switch it's... a little different. I guess I'll try to fit in a switch for that in the next version.
Title: MP3 repacker
Post by: Guillaume on 2012-07-12 18:23:44
That would be absolutely awesome, Omion. In addition, although I do see your point of it being a new file, which probably also means you're insisting on this in order to not get people confused between packed and non-packed files, as I see it though, really the point of MP3packer is not that of creating a "new file", but that of optimizing an existing (MP3) file. If one copies a file from one folder to another, the file's modification timestamp is also preserved. Yes, an MP3 file is rebuilt when using MP3packer, but it is not 'modified', so there's plenty of reason for the 'modification date/time' to be able to stay the same, even in case you're not using the -u parameter (hence the copy analogy). Just my two cents, and of course I can copy the file's timestamp back later on if I don't update the existing file, so it's not a high priority level issue, but if you'll let me I would very much like to use packing without losing the timestamp.
Title: MP3 repacker
Post by: nitrous on 2012-07-13 13:16:44
Sorry if this was asked before, but are you planning on releasing a multi-threaded version of this app? Right now it's using only the CPU0 instead of all 8 cores. Such feature would be awesome as almost everyone has at least a dual-core CPU.
Title: MP3 repacker
Post by: Guillaume on 2012-07-13 14:12:08
Sorry if this was asked before, but are you planning on releasing a multi-threaded version of this app? Right now it's using only the CPU0 instead of all 8 cores. Such feature would be awesome as almost everyone has at least a dual-core CPU.

I think it would be even easier to have the GUI WinMP3packer start 2-8 instances of mp3packer.exe simultaneously... Less work for sure and sufficient for a major performance boost in most scenarios. You could ask psyllium in http://www.hydrogenaudio.org/forums/index....showtopic=40780 (http://www.hydrogenaudio.org/forums/index.php?showtopic=40780)
Title: MP3 repacker
Post by: nitrous on 2012-07-13 15:02:01
Sorry if this was asked before, but are you planning on releasing a multi-threaded version of this app? Right now it's using only the CPU0 instead of all 8 cores. Such feature would be awesome as almost everyone has at least a dual-core CPU.

I think it would be even easier to have the GUI WinMP3packer start 2-8 instances of mp3packer.exe simultaneously... Less work for sure and sufficient for a major performance boost in most scenarios. You could ask psyllium in http://www.hydrogenaudio.org/forums/index....showtopic=40780 (http://www.hydrogenaudio.org/forums/index.php?showtopic=40780)

I've been doing this for a while, but even if you are running 8 instances of the app, it's not faster than an actual multi-thread optimized app.

A while ago I've made a test in video encoding using MeGUI. I have split a video file into 8 equal pieces and put them to encode simultaneously with MT option disabled. After that, I enabled the MT option and put the whole file into the encoder - it encoded almost 3 times faster. Multithreading is something more than just bruteforcing the app to use all available cores/CPUs.

The WinMP3Packer project seems abandoned without releasing the source code, so it's kinda pointless to contact the author.
Title: MP3 repacker
Post by: Omion on 2012-07-15 06:53:04
Sorry if this was asked before, but are you planning on releasing a multi-threaded version of this app?

Sure, how about right now (http://omion.dyndns.org/mp3packer/mp3packer-2.00.7z)? 
I have actually been working on a multithreaded version for over a year, but haven't been able to make it robust enough to release until now. This is just the first step, though - on my computer it uses about 1.5 cores. I should be expanding this in future versions to parallelize more of the processing.

The biggest improvement (and the main reason I bumped the version up to 2.00) is that I added SSE4.1 support. Most Intel processors made in the last 5 years support this. It makes the processing about 3x faster than the new non-SSE version, which itself should be faster than the algorithm used before 2.00. (It really seems like some of the SSE operations were designed for mp3packer -- PHMINPOSUW is amazing  )

To check if mp3packer uses the SSE instructions, run "mp3packer --help" and check the version line. If it says "SSE4.1" in there, it will default to using the SSE-enabled algorithm. You can still specify the non-SSE algorithm with the "--process base" switch if there are any bugs I haven't caught.

While I was at it, I also bundled the 64-bit version of mp3packer in the archive. I've made mp3packer 64-bit-capable since 1.00, but never gotten around to compiling it until now. The 64-bit version should be ~10% faster for -z processing than the 32-bit.

All in all, on my computer the 64-bit SSE version of 2.00 runs 7 times faster than 1.26.

[EDIT:]
One more question, undoubtedly posed before (sorry): is there any way to make MP3packer preserve the original file's modification date & time?
These dates are nice to preserve, because those indicate the times around which I discovered the bands/albums.

I also added this function to the program. Use the "--copy-time" switch to copy the timestamps. It will use all 3 creation, modification, and access times (except on Linux, where it will copy... some subset of those times... I think. The documentation wasn't exactly clear.  )
Title: MP3 repacker
Post by: lvqcl on 2012-07-15 08:21:16
It works fine, but leaves pipe.bin file after packing.
Title: MP3 repacker
Post by: nitrous on 2012-07-15 15:16:44
Sorry if this was asked before, but are you planning on releasing a multi-threaded version of this app?

Sure, how about right now (http://omion.dyndns.org/mp3packer/mp3packer-2.00.7z)? 


Aw, man, you are godlike! 
Now a 2600k is processing a mp3 file with -z option enabled for around a second, before the optimization it took like 10 seconds per file. If you manage to optimize the app even further by using the full potential of the CPU, the hypertheading technology and the SSE4.2 instructions set, it will process a whole discography in less than a minute. At the moment it uses around 20% of the CPU and processes a folder in around 1 minute.

I wish you good luck in this, I have high hopes in this program and in you.
Title: MP3 repacker
Post by: Guillaume on 2012-07-15 15:56:14
Omion, you are just plain fantastic, thank you so much!
Title: MP3 repacker
Post by: Porcus on 2012-07-15 16:05:09
The new version fails with a message that MSVCR90.dll is missing. Some googling (GAWD I hate these web sites that autogenerate entries for dll's, and auto-fills them with no information at all) indicates that this is a part of Visual Studio. Am I supposed to need this for merely calling the .exe?

XP 32-bit, running mp3packer.exe with or without parameters or file names.
Title: MP3 repacker
Post by: Martin F. on 2012-07-15 17:25:27
Install Visual C++ 2008 Redistributable Package (https://www.microsoft.com/en-us/download/details.aspx?id=29) and the service pack (https://www.microsoft.com/en-us/download/details.aspx?id=5582).
Title: MP3 repacker
Post by: lvqcl on 2012-07-15 18:40:37
Updates are cumulative, and it is simpler to install only the latest VC++2008 runtime: http://www.microsoft.com/en-us/download/de...s.aspx?id=26368 (http://www.microsoft.com/en-us/download/details.aspx?id=26368)
Title: MP3 repacker
Post by: Omion on 2012-07-15 21:01:15
It works fine, but leaves pipe.bin file after packing.

Oops.  That must have been there for a while. It was one of my debug files that I don't use anymore. I'll remove it in the next version, but until then the file can be safely deleted (or ignored).

The new version fails with a message that MSVCR90.dll is missing. Some googling (GAWD I hate these web sites that autogenerate entries for dll's, and auto-fills them with no information at all) indicates that this is a part of Visual Studio. Am I supposed to need this for merely calling the .exe?

XP 32-bit, running mp3packer.exe with or without parameters or file names.

Did it just start requiring that with 2.00, or does it say that with 1.26 and below too? I don't think I changed any of the linking.

It's sort of a pet peeve of mine to have external dependencies. I hate little downloaded programs that you need to install 25 "redistributables" in order to run properly. If I can, I'll try to get it to use static linking (it kind of puts that DLL into the EXE file). The problem with that is that I would have to update the program if Microsoft discovers a security flaw in the runtime.
Title: MP3 repacker
Post by: jaybeee on 2012-07-15 21:23:21
The new version fails with a message that MSVCR90.dll is missing. Some googling (GAWD I hate these web sites that autogenerate entries for dll's, and auto-fills them with no information at all) indicates that this is a part of Visual Studio. Am I supposed to need this for merely calling the .exe?

XP 32-bit, running mp3packer.exe with or without parameters or file names.

Did it just start requiring that with 2.00, or does it say that with 1.26 and below too? I don't think I changed any of the linking.

It's sort of a pet peeve of mine to have external dependencies. I hate little downloaded programs that you need to install 25 "redistributables" in order to run properly. If I can, I'll try to get it to use static linking (it kind of puts that DLL into the EXE file). The problem with that is that I would have to update the program if Microsoft discovers a security flaw in the runtime.

Yeah,  just happened to me too. Only with v2.00. If I use 1.26 it is ok. And it still doesn't want to work after installing the latest VC++2008 runtime as per lvqcl's link.
Title: MP3 repacker
Post by: Omion on 2012-07-15 21:54:47
Yeah,  just happened to me too. Only with v2.00. If I use 1.26 it is ok. And it still doesn't want to work after installing the latest VC++2008 runtime as per lvqcl's link.

That's even weirder. I'll look into it.

BTW, jaybeee, do you also run Windows XP?
Title: MP3 repacker
Post by: jaybeee on 2012-07-15 22:06:20
Yeah,  just happened to me too. Only with v2.00. If I use 1.26 it is ok. And it still doesn't want to work after installing the latest VC++2008 runtime as per lvqcl's link.

That's even weirder. I'll look into it.

BTW, jaybeee, do you also run Windows XP?
yup, XP SP3
Title: MP3 repacker
Post by: Porcus on 2012-07-15 22:17:21
Downloaded 1.26 and can confirm jaybeee's observation. 1.25.7 I have used for weeks without needing the DLL.
Title: MP3 repacker
Post by: Omion on 2012-07-15 22:43:24
Yeah,  just happened to me too. Only with v2.00. If I use 1.26 it is ok. And it still doesn't want to work after installing the latest VC++2008 runtime as per lvqcl's link.

That's even weirder. I'll look into it.

BTW, jaybeee, do you also run Windows XP?

HEY! I'm getting a weird error running that too!  It looks like my compiler didn't add a manifest to the EXE file (for some reason). It ran just fine on my computer until I moved the EXE file to a different directory (but now it's not running at all).

The 64-bit version seems to work just fine, so the easiest thing to do would be to buy a 64-bit capable computer, install a 64-bit OS on it, then run the 64-bit program 
If that's not an option, here's 2.01 (http://dl.dropbox.com/u/5833814/mp3packer/mp3packer-2.01.7z). It should work the same way as 1.26. I'll update the thread's other links in a bit.
Title: MP3 repacker
Post by: Porcus on 2012-07-15 22:54:07
Works!

Edit: timed the -z repacking of one (already well packed) file just for the heck of it. Down from 86 seconds with 1.26 to 24 seconds with 2.01. Tried it again, same result.
(CPU: Dual core Turion mobile.)
Title: MP3 repacker
Post by: jaybeee on 2012-07-16 10:03:58
here's 2.01 (http://dl.dropbox.com/u/5833814/mp3packer/mp3packer-2.01.7z). It should work the same way as 1.26. I'll update the thread's other links in a bit.
magic, works great. Thanks Omion
Title: MP3 repacker
Post by: Guillaume on 2012-07-16 11:23:53
Wow, 50-55x, not even using full 100% CPU, that's so fantastic
Title: MP3 repacker
Post by: Guillaume on 2012-07-16 11:56:23
Why is all this in ALL of my MP3 files now?

Code: [Select]
	ñ	 4âÇ  mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01- ¹d"­  i  
  ñ   4Ç  mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01- ¹dD­  i  
  ñ   4Ç  mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01- ¹df­  i  
  ñ   4Ç  mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01- ¹dê­  i  
  ñ   4Ç  mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01- ¹d¬­  i  
  ñ   4Ç  mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01- ¹d╠­  i  
  ñ   4Ç  mp3packer2.01-249
mp3packer2.01-2Ç­ %2£!ÃF╦îæ╗H $  Æ p£ËJpƒ¶º;å└ ¹d¯­  i  
  ñ   4Ç  Ç└qÜëcRm®Mvõ
or how about this:
Code: [Select]
mp3packer1.25-237(NoUniOutput)
mp3pac ¹dÅ­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d:Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d\Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d~Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹dáÅ­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d┬Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹dõÅ­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
Title: MP3 repacker
Post by: Omion on 2012-07-16 15:40:01
That's the padding in the file. It's rare that every single byte is used for data in an MP3 file due to the limited number of frame sizes. Even with mp3packer's output there are usually a few bytes at the end of the file that aren't used for data.

The part that you posted looks like a bunch of 32kbps frames, which will happen commonly at the beginning of a song if there is silence. If the silence lasts for more than about .25 seconds then there will be some bytes in the MP3 stream that are unreachable by the rest of the file, so they are sort of "wasted".

mp3packer puts the version string into the padding, since something has to go there.

It's important to note that it doesn't use up any extra space - it only fills in the blank bytes that have to be there.

Why is all this in ALL of my MP3 files now?

Code: [Select]
	ñ	 4âÇ  mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01- ¹d"­  i  
  ñ   4Ç  mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01- ¹dD­  i  
  ñ   4Ç  mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01- ¹df­  i  
  ñ   4Ç  mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01- ¹dê­  i  
  ñ   4Ç  mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01- ¹d¬­  i  
  ñ   4Ç  mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01-249
mp3packer2.01- ¹d╠­  i  
  ñ   4Ç  mp3packer2.01-249
mp3packer2.01-2Ç­ %2£!ÃF╦îæ╗H $  Æ p£ËJpƒ¶º;å└ ¹d¯­  i  
  ñ   4Ç  Ç└qÜëcRm®Mvõ
or how about this:
Code: [Select]
mp3packer1.25-237(NoUniOutput)
mp3pac ¹dÅ­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d:Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d\Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d~Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹dáÅ­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d┬Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹dõÅ­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
mp3pac ¹d Å­  i  
  ñ   4Ç  mp3packer1.25-237(NoUniOutput)
mp3packer1.25-237(NoUniOutput)
Title: MP3 repacker
Post by: Guillaume on 2012-07-16 15:47:53
Yeah I assumed it was padding, but I started to doubt that once I saw the amount of occurrences (did you see that in the second quote, damn!). But I guess my assessment of how much padding can actually still be there was faulty. Having the phrase "mp3packer" and its version in there is a good call, though.
Title: MP3 repacker
Post by: jaybeee on 2012-07-16 21:11:45
Updated the MP3Packer HA.org wiki (http://wiki.hydrogenaudio.org/index.php?title=MP3packer)

Mostly minor changes, except of course I detailed the latest version to be 2.01.

I also created a zip file with WinMP3Packer & mp3packer v2.01

I've left the "originally" packaged WinMP3Packer & mp3packer v1.20 there just in case there are any issues with this new 2.01 release. afaik the v1.20 was fairly stable and was around for a few years so many people would've used it. If it adds confusion they I'll remove it.
Title: MP3 repacker
Post by: Porcus on 2012-07-16 23:30:58
Updated the MP3Packer HA.org wiki (http://wiki.hydrogenaudio.org/index.php?title=MP3packer)



Nitpicking and suggestions:

- I see that unicode support has been added under Features, so why not mention multicore support? By all means, mention that this is only in recent versions.

- And 64-bit support (precompiled Windows executable builds for 32 and 64 bit available).

- Why say “--preset insane” rather than “320 kb/s”? The former is LAME-specific, the latter is not. I have noticed 10 percent reduction on iTunes-encoded files as well. (Case: my http://scionav.com/collection/750/Enslaved...leeping-Gods-EP (http://scionav.com/collection/750/Enslaved---The-Sleeping-Gods-EP), as downloaded from that source with lots of iTunes tagging, is now down to 288. That's average over a 5-song twenty-eight-and-a-half-minutes EP.)
Then OTOH I have also had a -z resulting in VBR 319 from a LAME-encoded 320.

- There's a slash too much in the external link to http://de.wikipedia.org/wiki/Xing-Header (http://de.wikipedia.org/wiki/Xing-Header) (that document isn't very informative either ... isn't there a HA thread?)

- “Many people also use” ... I am not so sure how many. It is also used for, or can also be used for ... oh well.

- Also a limitation: It can not repack freeformat mp3's. (Which, fortunately, there aren't many of.)
Title: MP3 repacker
Post by: jaybeee on 2012-07-17 12:02:16
Updated the MP3Packer HA.org wiki (http://wiki.hydrogenaudio.org/index.php?title=MP3packer)

Nitpicking and suggestions:

- I see that unicode support has been added under Features, so why not mention multicore support? By all means, mention that this is only in recent versions.
added

- And 64-bit support (precompiled Windows executable builds for 32 and 64 bit available).
added

- Why say “--preset insane” rather than “320 kb/s”? The former is LAME-specific, the latter is not. I have noticed 10 percent reduction on iTunes-encoded files as well. (Case: my http://scionav.com/collection/750/Enslaved...leeping-Gods-EP (http://scionav.com/collection/750/Enslaved---The-Sleeping-Gods-EP), as downloaded from that source with lots of iTunes tagging, is now down to 288. That's average over a 5-song twenty-eight-and-a-half-minutes EP.)
Then OTOH I have also had a -z resulting in VBR 319 from a LAME-encoded 320.
The originator of the mp3packer wiki page copied the text that Omion posted in the first post in this thread. I have changed it to -b 320

- There's a slash too much in the external link to http://de.wikipedia.org/wiki/Xing-Header (http://de.wikipedia.org/wiki/Xing-Header) (that document isn't very informative either ... isn't there a HA thread?)
changed to the HA.org Xing wiki page

- “Many people also use” ... I am not so sure how many. It is also used for, or can also be used for ... oh well.
changed

- Also a limitation: It can not repack freeformat mp3's. (Which, fortunately, there aren't many of.)
added
Title: MP3 repacker
Post by: Steve Forte Rio on 2012-07-17 15:18:55
Core i3 530 (2.93 GHz)

Code: [Select]
32-bit base - 26x
32-bit sse41 - 60x

64-bit base - 31x
64-bit sse41 - 72x


Thank you!
Title: MP3 repacker
Post by: no404error on 2012-07-18 13:01:22
Intel i7-3770, Lame 3.100a0, mp3packer64

Code: [Select]
a016-vbr.mp3 686.95x
a032-vbr.mp3 343.89x
a048-vbr.mp3 247.29x
a064-vbr.mp3 199.26x
a080-vbr.mp3 181.80x
a096-vbr.mp3 171.76x
a112-vbr.mp3 135.82x
a128-vbr.mp3 126.14x
a160-vbr.mp3 123.63x
a192-vbr.mp3 118.90x
a256-vbr.mp3 116.60x
a320-vbr.mp3 114.46x
c016-vbr.mp3 649.94x
c032-vbr.mp3 334.46x
c048-vbr.mp3 242.32x
c064-vbr.mp3 199.47x
c080-vbr.mp3 179.10x
c096-vbr.mp3 167.15x
c112-vbr.mp3 134.31x
c128-vbr.mp3 130.14x
c160-vbr.mp3 122.45x
c192-vbr.mp3 118.90x
c256-vbr.mp3 114.46x
c320-vbr.mp3 109.49x
vn00-vbr.mp3 113.45x
vn01-vbr.mp3 116.67x
vn02-vbr.mp3 117.74x
vn03-vbr.mp3 121.22x
vn04-vbr.mp3 123.63x
vn05-vbr.mp3 126.14x
vn06-vbr.mp3 131.47x
vn07-vbr.mp3 167.15x
vn08-vbr.mp3 193.27x
vn09-vbr.mp3 213.14x
vo00-vbr.mp3 115.56x
vo01-vbr.mp3 116.67x
vo02-vbr.mp3 116.60x
vo03-vbr.mp3 122.37x
vo04-vbr.mp3 124.91x
vo05-vbr.mp3 124.91x
vo06-vbr.mp3 128.75x
vo07-vbr.mp3 167.15x
vo08-vbr.mp3 176.64x
vo09-vbr.mp3 206.08x
Title: MP3 repacker
Post by: Porcus on 2012-07-18 19:10:39
I compared a troublesome .mp3 with 1.25.7 and 2.01. Both -z. The former warns against too many frequencies. The latter doesn't. Don't know if this is bug or improvement.
Title: MP3 repacker
Post by: Omion on 2012-07-18 20:33:03
I compared a troublesome .mp3 with 1.25.7 and 2.01. Both -z. The former warns against too many frequencies. The latter doesn't. Don't know if this is bug or improvement.

It's a bit of a bug. I guess I forgot to move that warning to my new dequantization routine. I'll add it back in the next version, but it's a fairly minor warning anyway so it can be easily ignored. Thanks for the report!

In other news, I just made what seems to be a fairly generalized and deadlock-proof threadpool algorithm. I hope to process multiple frames in parallel with this, instead of just multiple granules as in 2.00/2.01. Hopefully I'll get 100% multi-core CPU usage and a linear speed increase with this.
Title: MP3 repacker
Post by: no404error on 2012-07-19 13:13:06
Edit: Never mind  It's fs fault.
Title: MP3 repacker
Post by: Omion on 2012-07-29 05:30:37
2.02 is out (http://omion.dyndns.org/mp3packer/mp3packer-2.02.7z) (mirror (http://dl.dropbox.com/u/5833814/mp3packer/mp3packer-2.02.7z))

I changed how it handles the multithreaded stuff, so it should be able to use more CPU power if available. I also made it more efficient so it should go faster per CPU second anyway.
I also added CRC checking for the input files. Incorrect CRCs are reported with other errors, and frames with incorrect CRCs will skip -z processing.

One test I ran on my 8-logical-core processor with -z:
2.01 x64: 129.45x with ~17% CPU usage
2.02 x64: 364.06x with ~29% CPU usage

Files which report no errors will be bit-identical outside of the padding.


I would also like to request a bit of community feedback:
I set the default number of -z processing threads to 3 since that's the best on my processor (i7-2600k). I'd like some info from anybody who happens to use my program on other processors which --workers setting gives the best speed on a fairly long CD-quality file, along with the processor you have.

So run:
Code: [Select]
mp3packer -f -z --workers # path\to\some_file.mp3 NUL

changing the --workers number from 0 to however many cores the OS reports. Then PM me or post in this thread which --workers setting was the fastest. (Using NUL as the output will throw out the resulting file)

I'd especially be interested in anyone with an AMD Bulldozer CPU. Thanks! 
Title: MP3 repacker
Post by: Destroid on 2012-07-29 21:23:39
Processed MP3 file created with LAME 3.99 -b 320 (duration 39:32, 90813 frames), running i5-2500k, 8GB, WinXP x64 SP2.
Code: [Select]
MP3packer 2.01 (x86) -z   92.35x
MP3packer 2.01 (x64) -z  104.20x

MP3packer 2.02 (x86) -z --workers 0  121.65x
MP3packer 2.02 (x86) -z --workers 1  218.46x
MP3packer 2.02 (x86) -z --workers 2  247.68x
MP3packer 2.02 (x86) -z --workers 3  253.45x
MP3packer 2.02 (x86) -z --workers 4  246.08x

MP3packer 2.02 (x64) -z --workers 0  146.97x
MP3packer 2.02 (x64) -z --workers 1  261.32x
MP3packer 2.02 (x64) -z --workers 2  291.97x
MP3packer 2.02 (x64) -z --workers 3  308.57x
MP3packer 2.02 (x64) -z --workers 4  311.73x
I wasn't sure if worker parameter was in addition to the main program thread or not, so I ran it with "4" anyway.

Also, when using your suggested NUL parameter the program kept crashing at the same point in processing :shrug:
Code: [Select]
D:\audio>mp3packer -f -z --workers 1 btttol.mp3 NUL

*** 'btttol.mp3' -> 'NUL'
43% done on frame 39049
Title: MP3 repacker
Post by: no404error on 2012-07-30 12:47:23
Intel i7-3770

Quote
1 - 252.44x/242.59x/242.59x/247.26x/1394.87x/757.33x*
2 - 294.45x/281.14x/287.42x/294.45x/1485.97x/825.57x*
3 - 281.14x/274.73x/281.14x/287.42x/1470.75x/835.87x*
4 - 287.85x/268.61x/268.98x/274.73x/1283.16x/774.27x*
5 - 268.98x/268.61x/268.61x/274.73x/1246.18x/743.85x*
6 - 268.98x/268.61x/274.73x/274.73x/1226.58x/753.90x*
7 - 268.98x/257.49x/263.11x/274.73x/1204.46x/744.11x*
8 - 242.59x/252.11x/247.26x/252.11x/1179.81x/738.09x*

Quote
1 - 287.42x/280.73x/287.42x/287.42x/1801.70x/648.19x
2 - 334.25x/325.23x/334.25x/333.67x/2099.14x/688.46x
3 - 363.89x/353.23x/353.23x/353.23x/2167.60x/761.62x
4 - 353.23x/343.78x/353.23x/353.23x/1840.04x/824.90x
5 - 343.17x/353.23x/343.17x/353.23x/1519.79x/744.40x
6 - 334.25x/343.17x/343.17x/353.23x/1392.56x/672.97x
7 - 325.23x/325.23x/325.23x/317.21x/1320.33x/633.84x
8 - 294.00x/301.35x/294.45x/301.35x/1235.45x/593.71x

* mp3packer86/test6.mp3 = Sync error on frame 513803, CRC error on frame 513803-1198044.

Code: [Select]
=== test1.mp3 ===
INFO:
 MPEG1 layer 3
 7383 frames
 44100 Hz
 38.281250 frames per second
 192.862041 seconds
 6688676 bytes in file (277.449143 kbps)
 6688259 bytes in MP3 frames (277.431846 kbps) = current bitrate
 51353241 bits of payload data (266.269302 kbps)
 6422380 bytes of payload data (266.403071 kbps)
 25799 bits wasted from partially-full bytes (0.133769 kbps)
 6688168 bytes of MP3 data (277.428071 kbps) = minimum bitrate possible
 91 bytes of padding (0.003775 kbps)
 417 bytes outside MP3 frames (0.017297 kbps)
 0 sync errors
 Bitrate distribution:
  160: 1,0
  192: 3,0
  224: 1489,0
  256: 2640,0
  320: 3250,0
 Largest frame uses 9616 bits = 1202 bytes = 368.112500 kbps
 Smallest bitrate for CBR is 320

=== test2.mp3 ===
INFO:
 MPEG1 layer 3
 7383 frames
 44100 Hz
 38.281250 frames per second
 192.862041 seconds
 7715525 bytes in file (320.043279 kbps)
 7714481 bytes in MP3 frames (319.999974 kbps) = current bitrate
 58088768 bits of payload data (301.193370 kbps)
 7264287 bytes of payload data (301.325734 kbps)
 25528 bits wasted from partially-full bytes (0.132364 kbps)
 7530075 bytes of MP3 data (312.350734 kbps) = minimum bitrate possible
 184406 bytes of padding (7.649240 kbps)
 1044 bytes outside MP3 frames (0.043306 kbps)
 0 sync errors
 Bitrate distribution:
  320: 754,6629
 Largest frame uses 11735 bits = 1467 bytes = 449.230469 kbps
 Smallest bitrate for CBR is 320

=== test3.mp3 ===
INFO:
 MPEG1 layer 3
 7383 frames
 44100 Hz
 38.281250 frames per second
 192.862041 seconds
 7667515 bytes in file (318.051804 kbps)
 7667098 bytes in MP3 frames (318.034507 kbps) = current bitrate
 57836089 bits of payload data (299.883216 kbps)
 7232726 bytes of payload data (300.016570 kbps)
 25719 bits wasted from partially-full bytes (0.133354 kbps)
 7498514 bytes of MP3 data (311.041570 kbps) = minimum bitrate possible
 168584 bytes of padding (6.992936 kbps)
 417 bytes outside MP3 frames (0.017297 kbps)
 0 sync errors
 Bitrate distribution:
  224: 2,0
  256: 192,0
  320: 7189,0
 Largest frame uses 12044 bits = 1506 bytes = 461.059375 kbps
 Smallest bitrate for CBR is 320

=== test4.mp3 ===
INFO:
 MPEG1 layer 3
 7383 frames
 44100 Hz
 38.281250 frames per second
 192.862041 seconds
 6203381 bytes in file (257.318899 kbps)
 6202964 bytes in MP3 frames (257.301602 kbps) = current bitrate
 47471625 bits of payload data (246.142915 kbps)
 5937159 bytes of payload data (246.275896 kbps)
 25647 bits wasted from partially-full bytes (0.132981 kbps)
 6202947 bytes of MP3 data (257.300896 kbps) = minimum bitrate possible
 17 bytes of padding (0.000705 kbps)
 417 bytes outside MP3 frames (0.017297 kbps)
 0 sync errors
 Bitrate distribution:
  64: 1,0
  80: 13,0
  96: 41,0
  112: 25,0
  128: 13,0
  160: 58,0
  192: 351,0
  224: 2201,0
  256: 2741,0
  320: 1939,0
 Largest frame uses 9533 bits = 1192 bytes = 364.935156 kbps
 Smallest bitrate for CBR is 320

=== test5.mp3 ===
INFO:
 MPEG2.5 layer 3
 258229 frames
 11025 Hz
 19.140625 frames per second
 13491.147755 seconds
 94438176 bytes in file (56.000084 kbps)
 94438034 bytes in MP3 frames (56.000000 kbps) = current bitrate
 723951161 bits of payload data (53.661199 kbps)
 90564336 bytes of payload data (53.702969 kbps)
 563527 bits wasted from partially-full bytes (0.041770 kbps)
 93921313 bytes of MP3 data (55.693594 kbps) = minimum bitrate possible
 516721 bytes of padding (0.306406 kbps)
 142 bytes outside MP3 frames (0.000084 kbps)
 0 sync errors
 Bitrate distribution:
  56: 73780,184449
 Largest frame uses 4095 bits = 512 bytes = 78.380859 kbps
 Smallest bitrate for CBR is 56

=== test6.mp3 ===
INFO:
 MPEG2 layer 3
 1198046 frames
 22050 Hz
 38.281250 frames per second
 31295.895510 seconds
 625918038 bytes in file (160.000033 kbps)
 625917910 bytes in MP3 frames (160.000000 kbps) = current bitrate
 4861758484 bits of payload data (155.348118 kbps)
 607946965 bytes of payload data (155.406185 kbps)
 1817236 bits wasted from partially-full bytes (0.058066 kbps)
 623521563 bytes of MP3 data (159.387435 kbps) = minimum bitrate possible
 2396347 bytes of padding (0.612565 kbps)
 128 bytes outside MP3 frames (0.000033 kbps)
 0 sync errors
 Bitrate distribution:
  160: 660148,537898
 Largest frame uses 4095 bits = 512 bytes = 156.761719 kbps
 Smallest bitrate for CBR is 160
Title: MP3 repacker
Post by: Omion on 2012-07-30 15:35:59
Processed MP3 file created with LAME 3.99 -b 320 (duration 39:32, 90813 frames), running i5-2500k, 8GB, WinXP x64 SP2.

Thanks for the data! Your results are consistent with what I'm getting.
Quote
I wasn't sure if worker parameter was in addition to the main program thread or not, so I ran it with "4" anyway.

The worker threads are separate from the main thread. Whichever option you use for --workers, there should be 2 extra threads in the program - one for the OCaml GC and one for all of mp3packer's non-recompression stuff.

Quote
Also, when using your suggested NUL parameter the program kept crashing at the same point in processing :shrug:
Code: [Select]
D:\audio>mp3packer -f -z --workers 1 btttol.mp3 NUL

*** 'btttol.mp3' -> 'NUL'
43% done on frame 39049

Odd.  Maybe Windows XP has some limitations on how the NUL device is implemented. Or maybe I added something that only crashes the program if the writing happens faster than normal.


Intel i7-3770

It's good to see an Ivy Bridge chip. Thanks for the response!

Quote
* mp3packer86/test6.mp3 = Sync error on frame 513803, CRC error on frame 513803-1198044.

Does this mean that the 64-bit version did not find the same CRC/sync errors as the 32-bit version? That would be... unexpected.
Title: MP3 repacker
Post by: no404error on 2012-07-30 16:17:02
Does this mean that the 64-bit version did not find the same CRC/sync errors as the 32-bit version? That would be... unexpected.

log - https://dl.dropbox.com/u/5782249/log.7z (https://dl.dropbox.com/u/5782249/log.7z) (870kb)
file - uploaded (487Mb)
Title: MP3 repacker
Post by: BFG on 2012-07-30 18:57:04
I know I'm still a n00b here, so you'll have to forgive me if this is a dumb question

I know that MP3Packer can reduce the size of CBR320 (and other CBRs) quite a bit.  And, I suppose it would have a similar, but less extreme, effect on ABRs.
But I recently tried repacking a few random LAME VBR -V0 -q0, and the overall size reduction was only about 0.5%.
Is that similar to the experience others have had with LAME VBRs?  If so, I won't bother trying to repack my entire VBR collection.
Title: MP3 repacker
Post by: Dynamic on 2012-07-30 19:10:03
That's to be expected. Aside from brute force searching for the best data packing method, which takes too long for something like a 0.5% saving, LAME VBR uses the entire payload and any spare bits in frame N are carried over in the bit reservoir to encode some of the data of frame N+1, typically. (i.e. there's no waste, no padding bits, to be stripped out by mp3Packer)
Title: MP3 repacker
Post by: djonline on 2012-08-26 21:52:44
Bug in 2.03: --copy-time can't copy original file time when filename or filepath is cyrillic/non-latin.
Title: MP3 repacker
Post by: Omion on 2012-09-01 04:36:11
Bug in 2.03: --copy-time can't copy original file time when filename or filepath is cyrillic/non-latin.

Sorry about the delay. I haven't checked this thread for a while.

Anyway, 2.04 (http://omion.dyndns.org/mp3packer/mp3packer-2.04.7z) is out, and it should fix your problem. For some reason I didn't use the Unicode-aware version of the file functions for the copy-time stuff.
Title: MP3 repacker
Post by: djonline on 2012-09-01 08:21:10
Thank you, all work ok now!
Title: MP3 repacker
Post by: pwiecz on 2012-09-09 19:48:42
Hi,
Is the source expected to compile on anything but Windows?
I've tried to compile version 2.04 on MacOSX and had to fix a few issues. The first of them should affect Linux as well.
1) mp3frameutils-c.c:1259 Non Windows variant of mfu_find_best_config_sse41 calls mfu_find_best_config which is undefined. Should it be mfu_find_best_config_base ?
2) c_part.c:189 gettid() is not defined on MacOSX, but apparently the whole function get_os_thread_self_id() is not used, so this call is unnecassary.
3) c_part.c:230 stat struct on MacOSX (and BSD I guess) is defined inside "sys/stat.h" which is not included. According to http://linux.die.net/man/2/stat (http://linux.die.net/man/2/stat) this include should work on Linux as well.

With those fixes I've managed to compile it on MacOSX, but cannot tell if it works correctly (there are some differences with bitstream output form mpg123, but I can't tell if they are expected or not).

Best,
Piotr
Title: MP3 repacker
Post by: Omion on 2012-09-09 21:00:08
Hi,
Is the source expected to compile on anything but Windows?
I've tried to compile version 2.04 on MacOSX and had to fix a few issues. The first of them should affect Linux as well.
1) mp3frameutils-c.c:1259 Non Windows variant of mfu_find_best_config_sse41 calls mfu_find_best_config which is undefined. Should it be mfu_find_best_config_base ?
2) c_part.c:189 gettid() is not defined on MacOSX, but apparently the whole function get_os_thread_self_id() is not used, so this call is unnecassary.
3) c_part.c:230 stat struct on MacOSX (and BSD I guess) is defined inside "sys/stat.h" which is not included. According to http://linux.die.net/man/2/stat (http://linux.die.net/man/2/stat) this include should work on Linux as well.

With those fixes I've managed to compile it on MacOSX, but cannot tell if it works correctly (there are some differences with bitstream output form mpg123, but I can't tell if they are expected or not).

Best,
Piotr

I've tried to make it compilable on non-Windows platforms, but I don't actually test them. If it compiles with only those 3 changes, I'm impressed! However, note that the SSE optimization is not used outside of Windows.

It sounds like you made the right changes:
1) I renamed mfu_find_best_config to mfu_find_best_config_base a while back, so yes, that should change.
2) That function was used in an old version of the multithreaded code, but it was too slow so I used a different algorithm. I guess I left the old OS hooks in, though.
3) Since I don't compile the non-Windows ones I sometimes miss a few includes, and it clearly looks like that should have been included.

What sort of differences are there between the outputs? If everything works perfectly there should be no differences in the uncompressed output. However, one thing I learned very quickly in this project is that encoders sometimes do some quirky things that are handled differently by different decoders, so if they don't match up it could be one of many possibilities (most of which are benign).
Title: MP3 repacker
Post by: pwiecz on 2012-09-10 19:58:54
What sort of differences are there between the outputs? If everything works perfectly there should be no differences in the uncompressed output. However, one thing I learned very quickly in this project is that encoders sometimes do some quirky things that are handled differently by different decoders, so if they don't match up it could be one of many possibilities (most of which are benign).


I'm not sure how to debug differences.
At first I've just compared pcm files output from mpg123 -O file.pcm file.mp3 and could see some differences.
They were very small when the file was packed without -z option, and very substantial when I'd used -z.

Later I ran foobar's bitcomparator under wine, and it said that the bitstreams from original mp3 and the mp3 produced without -z were identical.
It still claimed there was a difference between the original mp3 and mp3 produced using the -z option.

I've tried it on a file produced by lame 3.99.5 form a cd rip.
Title: MP3 repacker
Post by: Porcus on 2012-09-11 11:45:02
Later I ran foobar's bitcomparator under wine, and it said that the bitstreams from original mp3 and the mp3 produced without -z were identical.
It still claimed there was a difference between the original mp3 and mp3 produced using the -z option.


I've experienced this as well.  Don't bother to find the posting, but Omion pointed out to me that the peak difference was ... -150 dB I think? That is likely a roundoff thing. Annoying if you are looking for "No differences" and have to look up every one of them, but likely to be transparent
Title: MP3 repacker
Post by: hidn on 2012-09-29 20:33:18
Great Job. It's pretty fast now.
Title: MP3 repacker
Post by: Ojay on 2012-10-20 10:04:12
I don't get the compilation under 64-bit Linux (pure 64-bit) with Ocaml 3.12.1:

Code: [Select]
ocamldep *.mli *.ml > .depend
File "mp3frameutils.ml", line 127, characters 26-30:
Error: Syntax error
File "mp3info.ml", line 119, characters 28-32:
Error: Syntax error
File "mp3queue.ml", line 149, characters 1-5:
Error: Syntax error
File "mp3read.ml", line 93, characters 28-32:
Error: Syntax error
File "types.ml", line 414, characters 5-6:
Error: Syntax error
make: *** [depend] Error 2


So what could that be?
Title: MP3 repacker
Post by: bugbear on 2012-10-22 11:58:09
I don't get the compilation under 64-bit Linux (pure 64-bit) with Ocaml 3.12.1:

Code: [Select]
ocamldep *.mli *.ml > .depend
File "mp3frameutils.ml", line 127, characters 26-30:
Error: Syntax error
File "mp3info.ml", line 119, characters 28-32:
Error: Syntax error
File "mp3queue.ml", line 149, characters 1-5:
Error: Syntax error
File "mp3read.ml", line 93, characters 28-32:
Error: Syntax error
File "types.ml", line 414, characters 5-6:
Error: Syntax error
make: *** [depend] Error 2


So what could that be?


I've just had this (compiling for Ubuntu). Solution: You need ocaml 4. To install this, I had to unistall all the ocaml packages, and compile/install from http://caml.inria.fr/ (http://caml.inria.fr/).

There were also a couple of errors AFTER that, but earlier posts in this thread showed how to fix them.

Sadly for me, having done all this, my purpose was not served. I was hoping to use mp3 repacker in conjunction with projectX to get "real" mp3 files; projectX spawns mp2 files from DVB streams.

http://project-x.sourceforge.net/ (http://project-x.sourceforge.net/)

But mp3 repacker does not repack mp2 (obvious in hindsight?)

  BugBear
Title: MP3 repacker
Post by: bugbear on 2012-10-23 08:21:18
Here are my diffs:

diff -r mp3packer-2.04/c_part.c pack_orig/mp3packer-2.04/c_part.c
21,23d20
< #include <sys/stat.h>
< #include <unistd.h>
<
192c189
<    // out_val = Val_int(gettid());
---
>    out_val = Val_int(gettid());
diff -r mp3packer-2.04/mp3framehuffman-c.c pack_orig/mp3packer-2.04/mp3framehuffman-c.c
337c337
< #if HAS_BYTESWAP
---
> #if 1
diff -r mp3packer-2.04/mp3frameutils-c.c pack_orig/mp3packer-2.04/mp3frameutils-c.c
1260c1260
<    return mfu_find_best_config_base(quant_bits_ptr, quant_bits_count1_char_ptr, scf_bands_ptr, quant_raw_ptr, debug_val);
---
>    return mfu_find_best_config(quant_bits_ptr, quant_bits_count1_char_ptr, scf_bands_ptr, quant_raw_ptr, debug_val);

Does anyone know a lossless converter from mp2 to mp3?

  BugBear
Title: MP3 repacker
Post by: mjb2006 on 2012-10-23 11:32:33
(Question answered in [a href='index.php?showtopic=97564']separate thread[/a].) Repacking MP2 frames to reallocate data among frames, as is done for MP3s, might be possible, but it is not possible to do it in a way that makes the MP2 audio data become MP3 audio data.
Title: MP3 repacker
Post by: timcupery on 2013-02-21 19:21:39
I've found a possible bug that I haven't seen described anywhere.
When converting an mp3 file with max frame size of 112kbps, to CBR, mp3packer will nevertheless convert the file to 128kbps instead of 112kbps. It even works with files that start out as 112kbps CBR: if I process them to VBR, and then back to CBR, the resulting CBR file is 128kbps. It seems that 112kbps is "skipped over" amongst CBR options; I haven't noticed this happening for any other mp3 bitrate.

This happens with older versions of mp3packer, and also with 2.04.

Thread here (http://www.hydrogenaudio.org/forums/index.php?showtopic=99604)
Title: MP3 repacker
Post by: JCZorkmid on 2013-03-07 17:32:41
Here are my diffs:


Thanks for these! I was able to compile mp3packer64 on OS X 10.8.2.

I saw you said the code using 'gettid' wasn't used, but if it's needed this should work on Mac OS X (you'll need to include pthread.h):

Code: [Select]
out_val = pthread_mach_thread_np(pthread_self());


Anyone have a test file (before/after) I can compare the output with to be sure things are working as expected?
Title: MP3 repacker
Post by: rbrito on 2013-04-08 03:58:55
I've tried to make it compilable on non-Windows platforms, but I don't actually test them. If it compiles with only those 3 changes, I'm impressed! However, note that the SSE optimization is not used outside of Windows.


Would you like some patches and results? I am trying to package it for myself (as a first step).

Later, I may package it for Debian, which would cover a lot of platforms, with different endianness, different sizes for ints etc. But let's start small first.

Here is what I have so far: https://github.com/rbrito/mp3packer (https://github.com/rbrito/mp3packer)

Quote
It sounds like you made the right changes:
1) I renamed mfu_find_best_config to mfu_find_best_config_base a while back, so yes, that should change.


Great.

Quote
2) That function was used in an old version of the multithreaded code, but it was too slow so I used a different algorithm. I guess I left the old OS hooks in, though.


So, the whole code can be ripped apart? Smaller is better, as always.  I had just created a mini-stub for gettid (which is Linux specific) as:

Code: [Select]
+int gettid() {
+       return syscall(SYS_gettid);
+}


Do you happen to have a github account? I can send you github pull requests with some janitorial stuff like this and, of course, I have fixed some variable definitions which were causing GCC to complain about unused variables (they were only used inside ifdefs for windows).

Quote
3) Since I don't compile the non-Windows ones I sometimes miss a few includes, and it clearly looks like that should have been included.


I'm willing to send you patches.

Quote
What sort of differences are there between the outputs? If everything works perfectly there should be no differences in the uncompressed output. However, one thing I learned very quickly in this project is that encoders sometimes do some quirky things that are handled differently by different decoders, so if they don't match up it could be one of many possibilities (most of which are benign).


I am not the original poster, but the build problems (not quality problems) that I am having are with versions 2.x of mp3packer. With versions 1.2x, I was (actually, am) having a wonderful time, especially when I use it with GNU parallel, which executes one process of mp3packer for each core/thread of my processors.

BTW, mp3packer (as is handbrake/x264) is a fine tool to see if you have heat problems with your CPU/system, while doing something useful.
Title: MP3 repacker
Post by: dj lists on 2013-08-14 10:06:06
Latest version 2.04 is much faster than 2.03 at running --ib but occasionally locks up. Trying this on a group of mp3s will cause it to lock up on different files. 2.03 does not lock up on the same set of mp3s. Happens with 32bit and 64bit versions.

** correction, 2.03 locks up as well. Also, doing it repeatedly on any random mp3 will eventually cause it to lock up.

Even more interesting, I got the 64bit version of 2.03 to lock up when displaying the help info (by giving no input file). It showed everything down to --help and then froze.
Title: MP3 repacker
Post by: ScottE on 2013-12-15 20:33:21
Here are my diffs:

diff -r mp3packer-2.04/mp3framehuffman-c.c pack_orig/mp3packer-2.04/mp3framehuffman-c.c
337c337
< #if HAS_BYTESWAP
---
> #if 1

Instead of that, a better approach is probably to use the gcc builtin.
Change

Code: [Select]
raw = _byteswap_ulong(*int_ptr) << s->bit_index;

to

Code: [Select]
raw = __builtin_bswap32(*int_ptr) << s->bit_index;

when using GCC.

The byteswap included in the !HAVE_BYTESWAP case doesn't really work on all architectures, so it's sadly probably more portable to use a GCC builtin than to have more #ifdefs. :-)
Title: MP3 repacker
Post by: goa pride on 2013-12-16 14:36:06
if you prefer use latest gui and latest encoder and latest 64bit encoder!
http://www.hydrogenaudio.org/forums/index....howtopic=103147 (http://www.hydrogenaudio.org/forums/index.php?showtopic=103147)
Title: MP3 repacker
Post by: Porcus on 2014-01-25 09:58:23
I nearly got down to 50 percent of original size on a track from this free download: http://grimtownmusic.com/2012/06/06/satanic-panic/ (http://grimtownmusic.com/2012/06/06/satanic-panic/)

The .zip file is 107 581 440 bytes including a pdf and a picture, unzips to 141 000 002 bytes (!),  of which 135 015 653 bytes music, the music mp3pack'd (with -z) down to 101 115 525 bytes. 

Now I am getting curious: seven out of twelve tracks are, according to fb2k, lame 3.98r V2 at 320 (EncSpot says 319). Didn't even know that was possible. They compress down to 202 - the "worst", track 4, down to 162. (161 according to EncSpot - couldn't it for the sake of the wow factor had gone down to 159?)

The reason why I do play with mp3packer from time to time, is to see how much is wasted by senseless encoding at usually 320 CBR. But this ... what have they done?
Title: MP3 repacker
Post by: [JAZ] on 2014-01-25 10:19:47
I am guessing that they used the -B ( minimum bitrate) switch. I.e. Encoding to "CBR" using the VBR engine.  Probably encspot shows 319 because there is silent parts encoded at 32kbps.
Title: MP3 repacker
Post by: robert on 2014-01-25 10:51:54
Actually, the lowercase b sets the minimum and uppercase B the maximum framesize. So, yes, it's possible to use the VBR engine to make constant bitrate encodings.
Title: MP3 repacker
Post by: [JAZ] on 2014-01-25 14:53:08
Duh! How bad for someone responsible of the LAME documentation (i.e. me) to make that mistake...    Thanks for correcting me.
Title: MP3 repacker
Post by: Porcus on 2014-01-25 16:15:22
Ah. So if I specify -b 320, then Lame will (at least would for 3.98) not attempt to make any use of the top ~100? Audio is usually not too well .zip-able.

Edit: I was wrong about 320 "CBR" yes - it was "VBR". V2, it seems.
Title: MP3 repacker
Post by: [JAZ] on 2014-01-25 18:19:53
Let's see if this example is clearer:

A) -V0  ~ 245kbps
B) -V9  ~ 65kbps

C) -V0 -b 64 -B 64  = 64kbps
D) -V9 -b 256 -B 256 = 256kbps

C is probably going to sound worse than B (the encoder will try to keep a level of detail unachievable with the provided bitrate), but their size will be about the same.

D is going to sound like B* (the codec is given more bits than those that it requires, but won't make use of them other than for block padding, and padding tends to be lots of zeroes, easily zip-able), but the size will be like A.


* In --vbr-old, D could sound better than B. This reasoning comes from the fact the older method was determining which bitrate was appropiate for the expected quality for the concrete block that it analized and then encoded it. That's why originally, the --alt-presets had -b 128, and even in the LAME history we can see some of the earlier versions having -b 64 as the default, to prevent the engine from guessing too low of a value.
--vbr-new does not work like that.
Title: MP3 repacker
Post by: Porcus on 2014-01-27 08:49:28
D is going to sound like B*


Thanks. 

Obviously, allowing the user to do what the user asks, is far from fool-proof :-)
Title: MP3 repacker
Post by: Porcus on 2014-02-09 14:05:45
Here is maybe a feature suggestion: Someone needs to extract a channel and "remux" it into a mono mp3 losslessly.

Two threads with different uses:
http://www.hydrogenaudio.org/forums/index....mp;#entry857571 (http://www.hydrogenaudio.org/forums/index.php?showtopic=104503&pid=857571&st=0&#entry857571)
http://www.hydrogenaudio.org/forums/index....showtopic=99206 (http://www.hydrogenaudio.org/forums/index.php?showtopic=99206)
Title: MP3 repacker
Post by: no404error on 2014-02-09 16:02:33
Here is maybe a feature suggestion: Someone needs to extract a channel and "remux" it into a mono mp3 losslessly.

Two threads with different uses:
http://www.hydrogenaudio.org/forums/index....mp;#entry857571 (http://www.hydrogenaudio.org/forums/index.php?showtopic=104503&pid=857571&st=0&#entry857571)
http://www.hydrogenaudio.org/forums/index....showtopic=99206 (http://www.hydrogenaudio.org/forums/index.php?showtopic=99206)

Good idea
Title: MP3 repacker
Post by: hidn on 2014-06-04 12:30:27
"Must Have" tool for sets. Big Thank You for Great Work.
Title: MP3 repacker
Post by: Jaff2002 on 2014-07-17 03:10:44
Personally I use a custom hacked version in wich I replaced version and padding with zero bytes in exe file. Compressing any MP3 files as archive gives best results. A good suggestion is remove padding in repacking the MP3 file.
Title: Re: MP3 repacker
Post by: kode54 on 2021-04-06 03:47:50
This project appears to have come farther:

https://github.com/ScottESanDiego/mp3packer

It still needs work. The string manipulation code needs to be remade for OCaml 4.08.0 and newer, because those default to force enabling safe strings at compile time of OCaml itself.

Edit: Oh, crud, just noticed this topic was from 2014. Well, that repo is slightly newer than that. But it needs specially built OCaml to build the mp3packer binary.
Title: Re: MP3 repacker
Post by: jaybeee on 2021-04-06 13:26:42
@kode54 how bizarre that I was just using this (via WinMP3Packer (https://wiki.hydrogenaud.io/index.php?title=MP3packer#WinMP3Packer)) this past weekend and even today. And just thought I'd check this thread to see last posts and here you are :-)
Title: Re: MP3 repacker
Post by: TheBigBadBoy on 2022-12-24 11:57:33
For anyone looking at a Linux build, I made one !

MP3Packer, version 2.04, 64-bit, compiled with optimizations (-O3), statically linked (needs glibc), stripped.
Linux x86_64


Already tested, and it is completely lossless and compress quite well ^^

File is hosted here: https://cdn.discordapp.com/attachments/1042536514783023124/1056003447205404682/mp3packer

Compiled from source code: https://github.com/ScottESanDiego/mp3packer

All the links before are now dead, so I thought it would be great to share this!

Send me messages if the download link is dead.
Title: Re: MP3 repacker
Post by: ScottE on 2023-04-27 23:32:10
Thanks for building that!  FWIW, modern OCaml doesn't really like building this (due to the `--unsafe-strings` flag).  If anyone wants to figure out how to build it w/o that settings, I'd appreciate it, and will update my repo.
Title: Re: MP3 repacker
Post by: TheBigBadBoy on 2023-04-28 07:50:37
I don't have the needed programming skills unfortunately, at least it compiles fine :) (we just have to build Ocaml ourselves in order to use `--unsafe-strings`).

Your message reminded me that I have a small update: use of `-flto`, compressed using UPX, and finally a static aarch64 build :))

The aarch64 build works on Android/Termux without any issue.
Both builds were compressed with `upx -9 --ultra-brute` 4.0.2, compiled statically with `-O3 -flto`, stripped and are generic architecture instructions.

I can't even attach them in this answer for whatever reason, so here are the links:
mp3packer_aarch64_clang_static: https://files.catbox.moe/8ehjyw
mp3packer_x86-64_clang_static: https://files.catbox.moe/s8c9dq

Again, if links are dead send me a msg
Title: Re: MP3 repacker
Post by: DoktorAvalanche on 2023-09-25 17:31:55
I recently ran mp3packer -z on just over 1 TB of LAME VBR encoded files. Looks like it saved about 8 kb per file.
Title: Re: MP3 repacker
Post by: Kraeved on 2024-03-06 03:45:27
Dear sound enthusiasts,
would you mind answering a few question related to MP3Packer?

a) How to repack VBR into CBR? I see no dedicated switch, but the possibility is mentioned (https://hydrogenaud.io/index.php/topic,79074.msg691086.html#msg691086).

b) The manual says -b stands for “minimum bitrate allowed for output” and its default is 0. Does this mean that a minimum bitrate of 32 (e.g. lame3995o (https://hydrogenaud.io/index.php/topic,112036.0.html) uses it to encode silence) might become 31-0? The older players might not like.

c) What's the point of minimizing and maximizing of bit reservoir with -r and -R?

d) Is there a way to use it in the Foobar2000's conversion chain (i.e. without manual invocation via foo_run)?
Title: Re: MP3 repacker
Post by: Octocontrabass on 2024-03-06 05:24:48
a) How to repack VBR into CBR?
Use the -i or --ib option to examine your MP3 to see the minimum bitrate required for CBR output. Subtract 1 from that number and then use it with the -b option and the resulting MP3 will be CBR. (Subtracting 1 selects unpadded CBR, which is usually what you want since it's slightly smaller.)

The minimum CBR bitrate calculations don't include the -z optimizations. If you use -z to repack a MP3 and examine it again afterwards, the minimum CBR bitrate might be lower.

b) The manual says -b stands for “minimum bitrate allowed for output” and its default is 0. Does this mean that a minimum bitrate of 32 (e.g. lame3995o (https://hydrogenaud.io/index.php/topic,112036.0.html) uses it to encode silence) might become 31-0? The older players might not like.
It means the minimum allowed for the MPEG version, which is unpadded 32kbps if your MP3 file is MPEG-1 or unpadded 8kbps if it's MPEG-2.

c) What's the point of minimizing and maximizing of bit reservoir with -r and -R?
If you're going to cut your MP3s with a program that isn't aware of the bit reservoir, using -r to avoid the bit reservoir can prevent some audible glitches after the cut. Using -R to fill the bit reservoir might be slightly faster? The default behavior is -r if you use -b, or -R if you don't use -b,
Title: Re: MP3 repacker
Post by: Porcus on 2024-03-06 05:45:44
d) No. fb2k converts by decoding and encoding.
mp3packer rewrites the encoded signal in a different way.

I was playing around with this ten years ago, and found out that there were quite a few wasteful MP3 files out there (as if CBR320 isn't wasteful in itself I mean) - see reply 579 up there, for example.
But beware that mp3packer can cause you trouble at track transitions, if those are not done properly in the original file.
Including, destroy gapless playback. The thing is, mp3 players are not screaming bloody murder at every possible irregularity: they are playing on as best as they can. And sometimes they successfully gloss over errors. And then you don't want a different (and zealous!) application to discard what it cannot handle.
So, use with care.