MP3 repacker Options

[Hallie08]

I note you have to know that mp3packer does not support mp3-freeformat(which exceeds the 320kbps) and mp3pro data..

And as you conclude there a tool for mp3,ogg, but still nothing for AAC and I think it would in the FAR future .. Many a tool to transcode AAC into AAC+ or HE-AAC

[Porcus]

Wishlist items: Unicode file name support, and after-write-verify.

(Playing a bit around with this certainly exposes Windows Explorer's failure to display VBR bitrates correctly :-o )

This post has been edited by Porcus: Jan 21 2012, 16:58

[Porcus]

and after-write-verify.

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

[Omion]

and after-write-verify.

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

[Porcus]

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.

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

[Porcus]

The following is however curious (at least to me). Used "--keep-bad in --keep-ok out" on a few folders, and got only two files differing, reported as follows:


Differences found: 1 sample(s), starting at 8.5073469 second(s), peak: 0.0000000 at 8.5073469 second(s), 2ch

Differences found: 2 sample(s), starting at 162.4575964 second(s), peak: 0.0000000 at 284.4125624 second(s), 1ch


(Re-did the exercise just to be sure.)


Maybe a Q for the foobar2000 forum?

This post has been edited by Porcus: Jan 31 2012, 14:53

[Omion]

1.24 is out! Get it here (mirror)

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.

This post has been edited by Omion: Feb 17 2012, 06:42

[Omion]

1.25 is now out. Get it here.
2 releases in 8 days! I'm on a roll!

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.

[Raimu]

@Omion:

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.

[Omion]

@Omion:

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.

Thanks.

[Raimu]

> Now to see how to fix it:
> Does this happen on every file you run?

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

> Do you have anything on the system that uses non-ASCII characters?

My Win language is English, but I type in a Finnish character setting. Other than that, I don't have any foreign character input methods in use - for example Cyrillic or Asian.

What is the output of the "chcp" command?

CODE

"Active code page: 850"

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

CODE

E:\>mp3packer -help

MP3 Packer version 1.25-237
Copyright 2006-2008 Reed "Omion" Wilson
[...]
  -help          Display this list of options
  --help         Display this list of options

E:\>dir
The system cannot write to the specified device.

The system cannot write to the specified device.

The system cannot write to the specified device.

The system cannot write to the specified device.

[Omion]

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.

[Raimu]

Sure thing, this one works.

[Porcus]

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.

This post has been edited by Porcus: Jul 4 2012, 14:24

[Guillaume]

This could be related to something else (I thought of something related to my new SSD, but it also happens on an external HDD) but I ONLY experience this while using mp3packer, so bear with me plz:

When using --keep-ok "out" at times mp3packer just quits with the error message that the original file could not be removed.

CODE

Repacking successful; deleting backup
Fatal error: exception Sys_error("Adam Green - (2002) Adam Green/01 - Apples, I'
m Home_org.mp3: Permission denied")

Via WinMp3Packer using v1.25, I get the following error every so often:

CODE

System.UnauthorizedAccessException: Access to the path 'E:\Music\D\Das Pop - (2003) The Human Thing\09 - The Machine.mp3' is denied.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileInfo.Delete()
   at WinMP3Packer.MainForm.KillFile(FileInfo fi)
   at WinMP3Packer.MainForm.KillFile(String fileName)
   at WinMP3Packer.MainForm.ProcessFile(PackerQueueItem item)Finished processing file.

I do not use any resident antivirus software or any other program that could prevent mp3packer from accessing the file...

This post has been edited by Guillaume: Jul 9 2012, 11:37

[Porcus]

CODE

Repacking successful; deleting backup
Fatal error: exception Sys_error("Adam Green - (2002) Adam Green/01 - Apples, I'
m Home_org.mp3: Permission denied")

There is a linebreak here. Does anything change if you remove the apostrophe from the filename?

[Guillaume]

No, it also happens on files without an apostrophe or any other special character.

[Guillaume]

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.

[robert]

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.

[Omion]

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 think I fixed it in 1.26. Give that a shot.

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

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)

[Guillaume]

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.

This post has been edited by Guillaume: Jul 12 2012, 12:11

[Raimu]

Thank you, Omion!

[Omion]

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.

[Guillaume]

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.

[nitrous]

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.