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.

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.

--------------------

[SIZE=1][B]Don't forget International Talk Like A Pirate Day! September the 19th![/B][/SIZE]

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

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

Yeah... that shouldn't happen. LAME data is actually in an MP3 frame, so mp3packer shouldn't treat it as "non-MP3 data". If it does, or some LAME data is not transferred correctly to the new file (which has been a problem in the past) then it needs to be fixed.

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

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

Yeah... that shouldn't happen. LAME data is actually in an MP3 frame, so mp3packer shouldn't treat it as "non-MP3 data". If it does, or some LAME data is not transferred correctly to the new file (which has been a problem in the past) then it needs to be fixed.

Well, mark that one up to (mayyyyyyyyyyyyyyyyyyybe) user error on my part I've been only partially able to reproduce the error when I've physically been trying to do it, maybe there is a bug or maybe there's not, but either way it won't stop me from using this app - and now I have full drag and drop and preset saving, you have a diehard fan

--------------------

[SIZE=1][B]Don't forget International Talk Like A Pirate Day! September the 19th![/B][/SIZE]