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]

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.

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.

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.

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

I've just now updated the .zip package for WinMP3Packer to include version 0.10 of the script.

Speaking of which...

i think i have read this fixes the nano suttering problems? righ?

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.

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.

eactly, so, anyone with nanos can test it?

Mmmm.... is it me, or mp3 repacker doesn't maintain the encoder_delay and encoder_padding from the LAME header?

Prev:


Post:



(Also... i got quite puzzled to see a 1/1000% saving :S this was a 3.90.3 --api )

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

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 )

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.

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.

I don't remember (I did it in 2003), but it's quite possible, since i wanted to do mixes..

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. I'm going to bed.

/me wait for the source code!

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

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.

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.

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.

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:


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.

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


Do you have any hints?
I have never heard of 'ocaml' before, so this is all new to me.

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]

Success!
Now on to testing this...

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

removed my URL. wrong package. sorry.

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.

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.

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)

1.02 out. Actually fixed the underrun this time. Also fixed another problem when a weird XING tag is present.

I'd like to try this, so if you could rehost it, that would be great.

@Architectonical: Check your PM

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

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.

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

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!

Omion, are you hosting your files on your machine because you want to, or because you have no choice?

I can mirror the files on my server for you, if you want.

If you use Linux, /dev/shm comes as a mounted ram disk automagically

I assume he's using Windows, since RAMDisk XP is about $50

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

or

http://users.compaqnet.be/cn021945/RAMDisk/ramdiskfree.htm

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

Here's a mirror. http://download.utorrent.com/mp3packer-1.03-123.rar
http://download.utorrent.com/mp3packer-1.03-123_src.rar

Version 1.0.3 of WinMP3Packer has been released here. Includes version 1.03 of mp3packer.exe

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.

I've checked that mp3 with mp3trim for any errors and found none. please find the "mp3packer -i" output bellow.


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

WinMP3packer fails to install on XP x64 - keeps asking for .NET framework 1.1.x, I have x64 .NET framework installed.

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.