Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: WinMP3Packer Beta released (Read 217842 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

WinMP3Packer Beta released

Reply #25
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.

WinMP3Packer Beta released

Reply #26
Will this run on the .NET Framework Version 2.0?

WinMP3Packer Beta released

Reply #27
Quote
Will this run on the .NET Framework Version 2.0?
[a href="index.php?act=findpost&pid=362823"][{POST_SNAPBACK}][/a]

Yep 

WinMP3Packer Beta released

Reply #28
Quote
Quote
Will this run on the .NET Framework Version 2.0?
[a href="index.php?act=findpost&pid=362823"][{POST_SNAPBACK}][/a]

Yep 
[a href="index.php?act=findpost&pid=362825"][{POST_SNAPBACK}][/a]
Cool, cheers

WinMP3Packer Beta released

Reply #29
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.

WinMP3Packer Beta released

Reply #30
Quote
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]

WinMP3Packer Beta released

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

WinMP3Packer Beta released

Reply #32
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:

Some idea?

thx in adv.

WinMP3Packer Beta released

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

WinMP3Packer Beta released

Reply #34
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.

WinMP3Packer Beta released

Reply #35
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.

WinMP3Packer Beta released

Reply #36
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.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

WinMP3Packer Beta released

Reply #37
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

WinMP3Packer Beta released

Reply #38
many thanks guys

WinMP3Packer Beta released

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


WinMP3Packer Beta released

Reply #41
thx 4 this version! much easier


WinMP3Packer Beta released

Reply #43
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

WinMP3Packer Beta released

Reply #44
^^ thanks psyllium

WinMP3Packer Beta released

Reply #45
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

WinMP3Packer Beta released

Reply #46
psyllium, you're a star.  Thanks for updating

WinMP3Packer Beta released

Reply #47
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.
Don't forget International Talk Like A Pirate Day! September the 19th!

WinMP3Packer Beta released

Reply #48
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.

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 .

WinMP3Packer Beta released

Reply #49
(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).