Or you can use EncSpot to see the bitrate distribution, if you prefer GUI applications.

~

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

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]

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:

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.

Thanks again! Works like a charm.

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

eval(system(dir)); //'

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.

Anyone tried to build this on OSX?

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/

NOTE: it requires DARWINE available here, 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

(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 ).

While this should not be audible I still wonder where it comes from...

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.

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.

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.

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?

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.

Thanks a lot apoc_metal !!!

Thing is your link is "not found", I found mp3packerx Here .

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

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.

After looking through the conformance files, I decided to let changes in CRC, copyright, and emphasis through. Version 1.20 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.

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...

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).

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.

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....

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....




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.

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)

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

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

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

Just found out about your tool So sexy!

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

Let me know if it doesn't work for you and I will try to help you get it working.

Cheers,
Tom