(Is the outfile supposed to have identical length as the original? One of my test files did in fact not.)

Sorry about the wait for the reply.

The output file should be the same length as the input file, but errors in the input file may make that not be the case. It's also sometimes because mp3packer adds an XING/LAME tag, which can show up as an extra music frame by some programs. Is the resultant file longer or shorter than the input?

About the other requests:write-after-verify should work already. Using "--keep-bad in --keep-ok out" will remove the old files if everything was OK, but will not save the new file if there was an error. Was there something else you wanted the program to do?

OCaml does not natively support Unicode, but I've added my own wrappers for Windows Unicode functions in the past. I haven't added it to mp3packer since it is OS specific, but I suppose I can set it as a conditional compilation. I'll see how easy it would be to shoehorn it in to this program when I get the time.

The output file should be the same length as the input file, but errors in the input file may make that not be the case. It's also sometimes because mp3packer adds an XING/LAME tag, which can show up as an extra music frame by some programs. Is the resultant file longer or shorter than the input?

On the fairly few issues encountered, output is some .02 to .03 seconds longer. These are files which are OK according to foobar2000's 'Verify integrity' function. (No wrong length reported, no decoding error.) BTW, the test for differences was also done with fb2k's 'Bit-compare' function.

QUOTE (Omion @ Jan 30 2012, 22:06)

"--keep-bad in --keep-ok out"

*blush* Should have thought of that combination.

A bit of playing around back and forth with -z: it might save a couple of percents on average – people do change lossless codecs over less of a reduction. But every now and then, a 320 CBR file proves its inefficiency – there was one album which was reduced by a whopping 15 percent. (No, not one of those with half an hour silence before a hidden bonus track, and yes, I checked the outfile was bit-identical). I have actually tried a few settings to try to provoke forth anything remotely close to this with a recent LAME, at no 'success'.

Had I just had a completely full 20 GB portable player as my a backup, the space saved would certainly be worth the effort. Now I'm not constrained on space (and I have a bit of files with unsupported characters), but it is still fun to play around with.

Only minor bug fixes this time. Valid input files will compress the same as before. The only differences are:Lots of warnings when -z gives an error (it was not always reported in the past)Slightly more strict with certain types of overflows

In conclusion: more console spam!

Oh, and the download is a 7zip archive this time. I lost WinRAR somewhere when I re-installed Windows, and I didn't bother to find it since I had already installed 7zip.

The major enhancement is Unicode support at last! It should be able to handle Unicode names in both files and directories, although it may not display them correctly due to command-line limitations.

I also made a few minor changes to the re-synchronization code, which should be faster for files with large amounts of non-MP3 data. One limitation is that now it will probably no longer support files larger than 1GB (unless you build a 64-bit binary). Actually, now that I think about it, that may have always been a limitation... I've never tested files that big.

I think you may've introduced something problematic into your latest version of mp3packer -- when used in a command prompt window on my Windows 7 x64, the command prompt goes nuts after having run mp3packer once. The cmd starts spouting out "The system cannot write to the specified device." errors and closing the window randomly. Commands stop working and the command prompt crashes out.

I have checked versions 1.20 and after that 1.24 to rule out a long-term incompatibility. It's only the 1.25 that messes up my W7/x64 comprompt.

I think you may've introduced something problematic into your latest version of mp3packer -- when used in a command prompt window on my Windows 7 x64, the command prompt goes nuts after having run mp3packer once. The cmd starts spouting out "The system cannot write to the specified device." errors and closing the window randomly. Commands stop working and the command prompt crashes out.

I have checked versions 1.20 and after that 1.24 to rule out a long-term incompatibility. It's only the 1.25 that messes up my W7/x64 comprompt.

It was almost certainly due to the Unicode stuff I added. It's rather impressive that the program crashes the entire command prompt Now to see how to fix it:

Does this happen on every file you run?Do you have anything on the system that uses non-ASCII characters?What is the output of the "chcp" command?

Also, if you could post the exact command you typed in and the response it would help.

It happens every time I run mp3packer in cmd, even if I don't define any parameters.

Ah! So it does this even when no processing takes place. That really narrows it down.I can't seem to reproduce the problem on my computer, but I'm pretty sure I know where it is.Try this version of the program. If that fixes it, I'll make it official within a few days.

A bit of playing around back and forth with -z: [...]every now and then, a 320 CBR file proves its inefficiency – there was one album which was reduced by a whopping 15 percent. (No, not one of those with half an hour silence before a hidden bonus track, and yes, I checked the outfile was bit-identical). I have actually tried a few settings to try to provoke forth anything remotely close to this with a recent LAME, at no 'success'.

More 320 files tested, and a reduction of 7 percent seems quite common, bringing the bitrate below the 300 mark. I acquired a few from services like http://www.scionav.com/index (in exchange of my mail address). It seems that iTunes is a widespread encoder these days (by tag ... EncSpot reports as FhG), and well, you should expect 7 percent reduction by -z'ing these 320's.Which isn't necessarily to say that 320 is itself inefficient on space – it could very well be that even professionals don't bother to use the CPU-intensive 'better' options? (EncSpot reports something on the psymodel, but I have no idea of what it means.)

I also tested decoding speed, to see if heavier packing penalizes the CPU on playback. Small difference: 129.5 x realtime for 320 CBR, 130.2 for the -z'ed 298 VBR's – this on a computer which decodes FLAC at 180 to 200 times realtime (good job, Coalson). Tool used: foobar2000's decoding speed test, all from RAM.

As I expected there are more problems with a delayed file handle closing on Windows 7 x64 to be found on various fora, not specific to mp3packer, but it does seem mp3packer is somehow affected by it. As a result, when attempting to remove the old file, it still looks like mp3packer is using it. I read something about compatibility modes, so now I'm trying to run mp3packer.exe in Vista SP2 compatibility mode. No problems so far, but only with a small sample set.

As I expected there are more problems with a delayed file handle closing on Windows 7 x64 to be found on various fora, not specific to mp3packer, but it does seem mp3packer is somehow affected by it. As a result, when attempting to remove the old file, it still looks like mp3packer is using it. I read something about compatibility modes, so now I'm trying to run mp3packer.exe in Vista SP2 compatibility mode. No problems so far, but only with a small sample set.

I didn't really know what the problem could have been until I saw Robert's post:

QUOTE (robert @ Jul 10 2012, 06:14)

Sounds like the typical pitfalls of RAII pattern, when a garbage collector is involved. But, neither do I know ocaml, nor the mp3packer source code. So it's only a guess.

OCaml doesn't garbage collect filehandles for that exact reason. However the clueless programmer who wrote the memory-mapping module (me ) relied on the garbage collector to clean up the memory map. If the map doesn't get closed, the file handle won't get closed and the file can't be deleted. So that was fixed.

I did some simple tests and it hasn't complained about permissions again. I also fixed a few issues with Unicode support (the fix for Raimu's problem is included, and renaming / deleting Unicode files should work)

Thank you so much for the quick fix, Omion! I'm currently transferring my music collection to another drive, so I thought it would be the best time to be (even more) strict about the tags and fixing them, and packing them afterwards.

One more question, undoubtedly posed before (sorry): is there any way to make MP3packer preserve the original file's modification date & time?These dates are nice to preserve, because those indicate the times around which I discovered the bands/albums.

One more question, undoubtedly posed before (sorry): is there any way to make MP3packer preserve the original file's modification date & time?These dates are nice to preserve, because those indicate the times around which I discovered the bands/albums.

There's no way to do that yet. I had resisted adding that support since the output file was actually a new file so it should have a new creation/modification date. However, if you use the -u switch it's... a little different. I guess I'll try to fit in a switch for that in the next version.

That would be absolutely awesome, Omion. In addition, although I do see your point of it being a new file, which probably also means you're insisting on this in order to not get people confused between packed and non-packed files, as I see it though, really the point of MP3packer is not that of creating a "new file", but that of optimizing an existing (MP3) file. If one copies a file from one folder to another, the file's modification timestamp is also preserved. Yes, an MP3 file is rebuilt when using MP3packer, but it is not 'modified', so there's plenty of reason for the 'modification date/time' to be able to stay the same, even in case you're not using the -u parameter (hence the copy analogy). Just my two cents, and of course I can copy the file's timestamp back later on if I don't update the existing file, so it's not a high priority level issue, but if you'll let me I would very much like to use packing without losing the timestamp.

Sorry if this was asked before, but are you planning on releasing a multi-threaded version of this app? Right now it's using only the CPU0 instead of all 8 cores. Such feature would be awesome as almost everyone has at least a dual-core CPU.