Hi all,

Some of you may have seen or used Omion's 'mp3packer' tool in this thread.

To make it a bit more user friendly, I've created a GUI for it:


Download Windows Installer version

A plain zip file without installer is also available.

Note: You will need the .NET Framework 1.1 redistributable which is available from here.

Reasons why you might want to use this tool:
. Reduce the size of high bitrate CBR files, turning them into VBR files. (This is the original idea of mp3packer)
. Take a Variable Bitrate (VBR) MP3 file and convert it into a Constant Bitrate (CBR) MP3 file. WinMP3Packer does this by finding a CBR bitrate that the VBR file will fit into.
This is useful if you want to play the audio on hardware players that do not support VBR files properly (e.g. Pioneer DJ equipment, CDJ-200)
. Strip headers from the start and/or end of the files.

Features in this version:
. Allows for batch processing - multiple files and folders may be selected.
. Allows for processing whole folders. Will also recurse into the sub-folders and process the files in there.
. When processing whole folders, the option 'Recreate sub-folders' will put the output files into the same sort of directory structure as the input files.

Let me know how it goes! There's no doco for this thing ... so if you have any questions just send me a PM.

Changelog:
----------
1.0.13 (22 Oct 2006)
- Includes new version 1.13 of mp3packer.exe
- Improved refresh rate of progress dialog when processing files.
- New option to 'Copy unprocessed MP3s' when using a custom output folder. This option will ensure all the input MP3s end up in the output folder regardless of whether they require processing or not.
- Fixed bug where the settings portion of the screen was not being disabled while processing.
- New option to 'Super-squeeze files' which sends option '-z' to mp3packer.exe
- New option to use an 'Alternate broken frame behaviour' which sends option '-w'
- New checkbox for input type 'All' which basically just checks the CBR and VBR checkboxes. This is just for GUI niceness and no other reason.
- New checkbox to enable/disable the 'Append text to filenames' option.
- When the 'Overwrite existing files' checkbox is enabled and the program has the same input/output filename for an operation, the existing file will be replaced by the newly processed file. The enable this behaviour, untick the 'Append text to filenames' option and set the 'Output folder' to 'Same as input'. This comes with a warning though: The original files will be replaced!
- The installation package now contains some example profile settings. These include the default settings and profiles to convert to CBR or VBR (these will overwrite the original mp3 files). The settings are stored in WinMP3Packer-config.xml. A copy of the new settings is available in WinMP3Packer-config-default.xml.

1.0.4 (15 Jul 2006)
- Includes new version 1.04 of mp3packer.exe
- Settings get saved into the file WinMP3Packer-config.xml in the same directory as the program. You can save different 'profiles' of settings which are all stored in the same file.
- Drag-and-Drop of files and folders into the processing list from Windows Explorer now works.

1.0.3 (10 Jun 2006)
- Includes new version 1.03 of mp3packer.exe
- Individual progress bar for each file is back.
- New 'About mp3packer' dialog accessible from clicking the 'mp3packer' version the status bar. This dialog will show the contents of mp3packer.html and also allows for the upgrading of the mp3packer.exe program.
- Removed the 'Delete original' files option as it didn't seem to work anyway.

1.0 (22 Apr 2006)
- New version based on the mp3packer.exe program. Perl is no longer required. Much faster.
- Created .msi installer package
- Removal of the individual progress bar for updating files for now.

0.4.1 beta (16 Feb 2006)
- Updated bundled mp3packer.pl to version 0.10 (bug-fixes).
- No changes to the front-end program itself.

0.4 beta (04 Feb 2006)
- Support for mp3packer.pl 0.09 (included in package).
- Multiple attempts at converting VBR->CBR are no longer necessary, thanks to the new switch, '-i' (thanks Omion). As a result, the 'attempts' field has been removed.
- Removed the 'Only for VBR input' option which was causing confusion.
- New options to filter out the input files depending on their type.
'Automatic' (the default) will convert only the files that need processing.
This means:
. When converting *to* VBR, only CBR files will be processed.
. When converting *to* CBR, only VBR files will be processed.
If you want all mp3 files to be processed no matter what, untick the 'Automatic' option and tick the CBR/VBR checkboxes as appropriate.
. Message box prompt when processing is complete, informing you of how many files were processed, skipped, or had errors.

0.3 beta (26 Jan 2006)
- Support for mp3packer.pl 0.08 (included in package).
- Support for multiple attempts at making CBR files. Will now loop from the average bitrate of the VBR file up to the largest packet size of the VBR file. e.g. 201kbps file may now be a 256kbps CBR file instead of a 320kbps CBR file. To revert to the old behaviour, set 'Attempts' to '2'.
- File list window now has icons, and will show you the bitrate and VBR/CBR type of the input files. There is no information available on the files within folders (... yet)
- Status window will show % complete in its title bar. Handy for when you are running it in the background.
- New option 'Only for VBR input' when in CBR mode. This is on be default. It means that if the input file is CBR, the output file will be CBR with the same bitrate.

0.2 beta (22 Jan 2006)
- Fix bug where output was not being captured properly - app was not determining VBR files in that case.
- Reduce logging when creating/checking directories.

0.1 beta (21 Jan 2006)
- Initial release

HOORAY!!!!!

Last night a DJ saved my life!!

Very nice psyllium

One thing I would change is the fact that your GUI requires the setting of a minimum bitrate, whereas you can just let the MP3 Packer to scan the file twice and automatically choose.

Other than it's superb

If you leave the setting on '0', it will figure it out... yeah I can see how it might cause extra confusion... I was thinking of relabelling '0' to 'Auto' ... I might do that for the next version.

A tip for anyone converting VBR -> CBR, if you know what the max bitrate is of the input files already (e.g. 320 or 256), if you select that in the GUI, it should only need to process each file once, as opposed to twice. Only a performance thing

Thanks for the feedback

Does the switch -b 0 mean auto then? I just leave the switch out usually

Yeah ... '-b 0' results in the defaut behaviour... which means that the lowest possible bitrate will be used wherever... but yeah I can see why you wouldn't bother typing it then !

Holy smokes!! I asked him the other day if maybe he could get the program to "deal with" sub folders, so I don't have to move my VBR mp3s around before I run them thru the program. I simply could not have asked for a better solution!!! It re-creates the dirs that your original music was in and then fills them full with the files with appended with either -vbr, or cbr, your choice. So now... I don't have to move any of my vbr mp3 files around (outside of their dirs), and I sure don't have to move the specific folders to a main dir for batch processing to begin with (like I'd imagined this might be solved thru)

I could not be any happier at all! wow! I don't even have any suggestions!! You are the MAN!! I wish I could take you to a bar and buy you some drinks!!! beers, tacos- whatever else you want!! you just saved me sooooo much hassle!! I'm going to convert hundreds of gigs of VBR mp3s to CBR and now take them out on the road with me to clubs and gigs with my cdj-200 units. These pioneers are now a rock-solid investment, in my eyes.

do you mind if I make a post over at pioneerprodjforums.com and explain to them how silly it is to recommend Easy CD creator for mp3 conversions like this. I'm sure they will be super-impressed. is your software strong enough to handle the massive onslaught of newbies that will surely follow?

Glad to hear you are happy with the program we were both in the same boat with the CDJ-200's... so I put it whatever I thought would be handy for me... heheh... you get em as a bonus



I've made a post over there already ... I didn't start a new thread cos I'm scared of DJ Pulse I replied to this post instead http://www.pioneerprodjforums.com/ubbthrea...ed&sb=5&o=&vc=1 and made a reply in the CDJ-200 VBR thread as well... I didn't want to plug it too much tho - but you can certainly feel free to post about it on the Pioneer forums...

I've uploaded a new version 0.2 beta to here. There was a problem where the application was not capturing the output from the script correctly. This would result in the second pass of the 'Force CBR' option to be skipped. Only seemed to happen on some PCs (fast ones? )

Can I make it ignore files that are allready VBR?

@psyllium:
Looks good! Definitely easier to use than the command line. This also gets me out of supporting folder recursion!

I also see that -M 40 is the default. Is that based on a percentage of the user's memory, or is it always 40? I was planning on making -M * the default, but couldn't figure out what to use, so I'll just take your default.

One thing about the CBR calculation: I'm assuming that your program takes the highest bitrate from the first pass and makes a CBR file at that bitrate. That works, but it's not always the best bitrate. The problem is that raising the smallest bitrate with the -b switch will increase the bit reservoir, which will tend to lower the highest bitrate. To do it correctly the following has to be done:
1) Figure out the average bitrate of the input file. You can't make a VBR file into a CBR file of lower bitrate unless the encoder did something wrong.
2) Put through mp3packer with -b set to the next larger valid bitrate
3) Keep raising -b until a CBR file is produced.
I think this method may need up to 10 passes, so I didn't bother.

@all:
Just to re-affirm, -b 0 gets turned into -b 32 in the program, which really means to use all the frame sizes. (Well, it turns into -b 16 for MPEG-2 files, but it still means the same)

Also, has anyone confirmed that the program produces files that work for the CDJ-200? I don't see why they wouldn't, but some feedback would be nice.

I understand how the CBR files should behave now - it will make the files smaller, but will take a bit longer to process. Is there a quick and easy way for me to find the bitrate of an input file? I know there's mp3info in the linux world, but we're in windows now

I might make it an option. I might also make the program save your last settings in the registry as well

And YES the CBR files that come out of the app *DO* work in the CDJ-200 - I burnt some to CD and played them (in my loungeroom setup, heheh) last night.

Well, it looks like mp3info has a Windows version, available here. Use "mp3info -x -r a file.mp3" to get the average bitrate.

The easiest way would be to read the LAME tag at the beginning of the file, which has the number of frames, then use that and the file size to get the average bitrate. However, since not everything writes a LAME tag, that's not always possible.

I can easily write something which spits out any LAME info found, then exits. I have the functions to read the tag in MP3.pm, so it wouldn't be hard.

Failing that, you could just start with -b 192, and if it gives a CBR file then try lower -b settings.


GREAT! I was actually having doubts with it. My program outputs a different kind of CBR than most programs. When you specify -b 320, you actually get 319.725kbps, since my program won't use padded frames with that much wasted space. That means my output bitrate is more constant than most CBR files, but I wasn't sure if the machine expected a normal CBR file or not.


One more thing that I noticed with the GUI: the options for -b go up to 448, I'm assuming it's since you read the %mp3::Bitrates variable at the top of mp3.pm. However, much of mp3.pm is more general than mp3packer is, and while mp3.pm can handle mp1 and mp2 files, mp3packer can not.

In summary, the only way to get a bitrate > 320 is to start with an mp1 or mp2, which are both invalid for mp3packer. The valid bitrates are as follows:

MPEG-1 layer 3 (most common):
32 40 48 56 64 80 96 112 128 160 192 224 256 320

MPEG-2/2.5 layer 3: (not nearly as common)
8 16 24 32 40 48 56 64 80 96 112 128 144 160

Specifying -b 320 on an MPEG-2 file will simply peg it to 160, so there's no real need to check for which version of MP3 the file is before processing. Also using e.g. -b 144 on an MPEG-1 file (where it is not a valid bitrate) will use the next higher valid bitrate (160). If that makes any sense.

It looks really good, psyllium. Wish I could download it and give it a try. But I refuse to have that [insert expletive here] .NET Framework anywhere near my machine.

Regards,
Madrigal

or in an 'ini' file?



EDIT: reads better now

Yeah I can understand where you are coming from... hell, I use linux as my primary OS at home... not Windows ... I develop in .NET for work though, so it was much easier for me to do it this way... I would have liked to have made a Java version, but I'm not a big fan of GUIs in Java...

A new version is on the way, to cater for version 0.08+ of mp3packer.pl. It is suggested that you use the bundled version 0.07 of mp3packer for now.

Here's a sneak preview:

Version 0.3 beta released:
- Support for mp3packer.pl 0.08 (included in package).
- Support for multiple attempts at making CBR files. Will now loop from the average bitrate of the VBR file up to the largest packet size of the VBR file. e.g. 201kbps file may now be a 256kbps CBR file instead of a 320kbps CBR file. To revert to the old behaviour, set 'Attempts' to '2'.
- File list window now has icons, and will show you the bitrate and VBR/CBR type of the input files. There is no information available on the files within folders (... yet)
- Status window will show % complete in its title bar. Handy for when you are running it in the background.
- New option 'Only for VBR input' when in CBR mode. This is on be default. It means that if the input file is CBR, the output file will be CBR with the same bitrate.

Thanks for the update and effort put into this GUI. And of ocurse thanks to Omion for the prog.
Does that mean it gets ignored, i.e. nothing happens at all to the file, or that it does go through some processing to amend the file? I assume nothing happens right? If so, maybe just reword your update to make it a little clearer.

CANT GET PERL TO WORK... is there any direct link to the app needed please???

The perl you need is linked to in this post from another thread.

Regards,
Madrigal

what exactly does the in-memory option do? I have 2 gigs of fast RAM. should I increase the # to a higher one? It seems to make it work faster, but I don't want to encourage the program to crash during a -huge- list of batch commands.

last night I converted almost 30 gigs of vbr mp3s to cbr. I never thought it could be this easy!!!

The way mp3packer works, it has to pre-parse the file in order to not run into problems with very large frames.
Normally (with the in-memory off) the first pass only returns how much data is in every frame, which is a fairly small overhead. However, this means the file needs to be re-read in order to get the actual data.
The in-memory option will actually read the file data on the first pass, so the file does not need to be read again during the second pass. The number represents the cutoff where all files smaller than that will be parsed in-memory, and everything larger than it will be read twice.

Since each file is processed separately, the max amount of memory taken up is determined by the largest file smaller than the cutoff value, times 2 (since Perl is not that efficient). So a small number of large files will take up more memory than a large number of small files.
With 2GB of RAM, you'd only run into problems with MP3 files larger than about 700MB, which I havenever run into. So you can safely set the limit to 700, but the actual amount of memory taken up will be much less.

I'm back from holidays now ... phew

The description I posted is actually correct - the files *WILL* get re-packed, but the output file will end up being the same bitrate as the input file. Ideally, I would have had time to add an option to decide whether to either ignore the CBR files, or process them anyway. Keep in mind that some people might use the program to strip the non-MP3 data at the beginning and/or end of the file, and would want the files processed no matter what... although I don't use it for that I reckon a new option, with some form of better description, will be available in the next version...

ok, cool

New version released. The major improvement in this one is the use of the '-i' switch in the perl script, which means multiple attempts at converting a file to CBR are not necessary. Also, the program will skip files it thinks does not need processing - this can be overridden by changing the 'Automatic' checkbox (and then the VBR or CBR checkbox next to it...)

0.4 beta (04 Feb 2006)
- Support for mp3packer.pl 0.09 (included in package).
- Multiple attempts at converting VBR->CBR are no longer necessary, thanks to the new switch, '-i' (thanks Omion). As a result, the 'attempts' field has been removed.
- Removed the 'Only for VBR input' option which was causing confusion.
- New options to filter out the input files depending on their type.
'Automatic' (the default) will convert only the files that need processing.
This means:
. When converting *to* VBR, only CBR files will be processed.
. When converting *to* CBR, only VBR files will be processed.
If you want all mp3 files to be processed no matter what, untick the 'Automatic' option and tick the CBR/VBR checkboxes as appropriate.
. Message box prompt when processing is complete, informing you of how many files were processed, skipped, or had errors.

Will this run on the .NET Framework Version 2.0?

Yep

Cool, cheers

Version 0.4.1 beta has been released. The only change is that the bundled version of mp3packer.pl has been upgraded to version 0.10.

Just letting you guys know that it shouldn't be too long before a new version of the app is released. Sit tight

hi!
this seems to be a great software!! But i cant get it to work
I download perl and install it. Then i run "WinMP3Packer-0.4.1beta"
But i still get this:

I dont understand how to get this to work

Some idea?

thx in adv.

It looks like you didn't install perl from activestate properly. If you did, try re-installing.

Version 1.0 released:
- New version based on the mp3packer.exe program. Perl is no longer required. Much faster.
- Created .msi installer package
- Removal of the individual progress bar for updating files for now. I'll add this again when I get some time .

Sorry for the delay in releasing, folks. I hope the new version (with the msi installer, and no requirement of perl) makes it a bit easier for some people.

One small note:
The GUI will now let you know what version of the mp3packer.exe program it is using. You will notice the program says that the version is 1.01-110, despite the actual .exe in the package being the latest available copy of the program, from the 1.02-112 package. I'm not sure whether this exe contains the latest fixes or not. Either way, I would expect it to only be a problem with very few files.

That exe was actually 1.01 (I was up too late ), but it has been replaced with the real 1.02 build. You're right, though; the bugs were fairly minor and only occured if you ran mp3packer on the output of a previous mp3packer output.

It's all updated now.

A fully updated version of WinMP3Packer which includes 1.02 of mp3packer.exe is now available from the same URL

many thanks guys

psyllium, could you please also release no-installer version?

No-installer version is available here (288.7kb).

thx 4 this version! much easier

mp3packer version 1.03 has just been released

Hey guys - If you are super keen to try the new version, you can take Omion's new mp3packer.exe and replace the existing one in the C:\Program Files\WinMP3Packer folder. When you run the program next, it will tell you what version of the exe you are running in the bottom right hand corner of the screen.

I'll rebuild an installer with the new exe soonish... when I boot into Windows next

^^ thanks psyllium

New version 1.0.3 released:
- Includes new version 1.03 of mp3packer.exe
- Individual progress bar for each file is back.
- New 'About mp3packer' dialog accessible from clicking the 'mp3packer' version the status bar. This dialog will show the contents of mp3packer.html and also allows for the upgrading of the mp3packer.exe program.
- Removed the 'Delete original' files option as it didn't seem to work anyway.

I'm going to try and keep my version numbers the same as the mp3packer.exe, so this version is 1.0.3. It's possible then that my versions might skip a few numbers here and there.

Oh and a non-windows installer version is also available here

psyllium, you're a star. Thanks for updating

I have a couple of bug reports / functionality comments re the GUI (1.0.3)... It works really well, and I'm very impressed at how easy it makes it to use the cmdline app, but there's a couple of what I'd call evaluation bugs more than anything else.

Basically, the way I use the software is like this: I load a VBR file into the software, leaving all the settings as defaults (Input Types: Automatic, Output Type: VBR, Minimum bitrate: Auto, Append text to filenames: -vbr, Strip non-MP3 data: no boxes ticked, Output folder: Same as input).

I do this to remove CRC data from the frames before I stick the MP3s (of radio shows) into MP3DirectCut to losslessly edit them, snip out bits I don't want and fade in / fade out the start and finish of the shows). Of course, if the MP3 has CRC data in when you do this editing, any decoder HATES it and basically just plays back white noise, so I was delighted to find this program which successfully strips out the CRC information without having to reencode. However, if I leave the options as the defaults, as stated above, I put the file in and hit Process, and it doesn't actually process the MP3 - it just skips it. It shows the VBR bitrate correctly in the Information column, and it shows the filename correctly in the Path column, but it just seems to not want to process the file.


The reason for this, it seems, is because Automatic doesn't recognise what flavour of MP3 it is (CBR or VBR) if you don't have any of the 'strip non-MP3 data' options checked (I don't want to strip out any of the non-MP3 data, as doing so strips out the lame header in the MP3s - and I want to keep that!) The way round this is, seemingly, to uncheck the Automatic box for Input Types and manually tick the VBR box (the CBR box is ticked by default if you leave it as Automatic). I'm guessing that the script which evaluates the MP3 file to see if it's VBR or CBR isn't actually called until you specify a command line switch and then hit Process - just hitting Process after loading an MP3 in starts the processing but somehow just doesn't 'see' the file for processing.

The way that only the CBR box is ticked by default if you untick Automatic is a bit annoying too, and I think it would make more sense to tick both the VBR and the CBR boxes, allowing the user to untick the one which they don't need, if they wanted to, as opposed to having to tick the box every time - another click which isn't needed. All in all, to process an MP3, it takes me no less than three clicks more than it should need (I untick CBR just to be on the safe side, as I only deal with VBR files)...


... At the end of the day, this bug isn't going to bring about armaggedon early, or kickstart World War 3, but it's just something I feel should be taken into consideration for 1.0.4 - they're the only two negatives (albeit minor ones, at that) I've found in an otherwise perfect GUI.

One other thing - DDE for the file window. It mildly surprised me that, having been built to use the .Net framework, I couldn't just drag and drop MP3 files straight into the white box which shows the files loaded into the GUI for processing - it's a very slight drag having to use the buttons to load either an entire dir or a particular file (these should be kept, as they're essential for accessibility and they're just plain useful sometimes, but my natural instinct is to drag MP3 files I want to process into the GUI, just like I do with the FLAC encoder frontend, and it frustrates me slightly when I remember - after I've tried to do it - that I can't actually drag and drop directly).

Mayyyyyyybe, if you do implement those changes, you could have the program save its configuration state in a flatfile (.ini/.cfg... etc)? That way changes could be persistent, removing the need to reselect options a second time round - that'd be the final perfect addition.


Please don't see me as the party pooper, by the way - I cannot mention the time, and most importantly of all, MP3 quality!, you and Reed Wilson have helped me save. I'm eternally grateful for your valuable contribution to my AV utilities arsenal, all I'm trying to do is suggest some feedback to help you finally perfect what is already a great combination of software.

These are all pretty valid responses. The program doesn't actually care what you set the checkboxes for for the parts where it is stripping the headers when determining what files to process. It's all based around the 'Automatic'/'CBR'/'VBR' options. The original idea for the program is to convert either CBR files into VBR files, or VBR files into CBR files. As a result of this, the 'Automatic' option will make it so it will only convert the files that it needs to convert.

I think this will be fixed with a configuration file - it'll save your last settings on closing of the application. This will mean you won't have to change the checkboxes again.

As far as drag-and-drop goes, I hadn't even thought about it. Good idea, I'll hopefully have it going in version 1.0.4.

Thanks for the feedback .

Are you just guessing this or have you really seen mp3packer stripping LAME tags? The latter could be a bug in mp3packer which you should report to Omion (see this thread for details).