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: MP3 repacker (Read 599665 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MP3 repacker

Reply #375
thanks for the response, but in any case, it looks like it got 100 MiB bigger, or i'm not seeing something?

MP3 repacker

Reply #376
If it's counting upwards from -(2^31) then it would be circa 100MiB less rather than more...
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

MP3 repacker

Reply #377

2932 items successfully processed and 100 items copied (In: -1732313922 bytes, Out: -1836620697 bytes).


From the numbers, it looks like a signed int is used for the number of bytes, which overflowed (possibly more than once, considering the number of files). So it's just a display error, the files actually became ~100MiB smaller in the process if that interpretation is correct.

Oh dear. You overflowed my integers. The max number OCaml can support is 2^30 - 1, so if you convert more than a gigabyte of songs it will give negative numbers.

The way integers overflow, you can still do standard math on them, so you saved (-1732313922)-(-1836620697)=104306775 bytes. The output is numerically less than the input, so you did actually save space.

I'll change that in the next version (whenever that comes out...  )

[edit] Wait a second... that's a WinMP3Packer message! You had me looking through my source for quite a while!  The command line gives no indication as to how many bytes were saved. It's all yours, psyllium! 


@RogerG:
Sorry about the delay. I guess I missed the update notification.
I'll see if it's easy to add a time to the error, instead of the frame number. It shouldn't be too hard to figure it out. In the meantime, you can actually do the math yourself:
44.1KHz: Seconds = Frame * 0.026122449
48KHz: s = f * 0.024
32KHz: s = f * 0.036

That equation is generally accurate. It depends on the starting offset stored in the XING tag, but it's never too far off.

[edit2]Now included in 1.19.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #378
thanks for the info

MP3 repacker

Reply #379
Could you please add an option for those who "ab-use" MP3Packer to create "optimal CBR" MP3 files, to simply use the detected minimum CBR bitrate and convert the file in a second pass right away (in one application call)? Or is your tool not made for 2 passes after each other?

As far as I understood (oh, well, english is not my native language, and the topic is already quite grown), for now I need to run the tool once, note down the detected minimum CBR bitrate, and enter it in a second call with different parameters.

MP3 repacker

Reply #380
Here is a fun aside.

I recently ran mp3packer -z on the new Radiohead album In Rainbows which is currently only available from inrainbows.com as a 160 kbps CBR LAME encode. This shaved 862,407 bytes from the album. Supposedly the album has been downloaded from the site 1.2 million times so far. If Radiohead had bothered to run mp3packer on In Rainbows they would have saved over 963 GB of upload bandwidth to date (nearly a terabyte).

MP3 repacker

Reply #381
Hi everyone!!!

I'm the bloke using a Mac and cdj's!
The easiest solution was to find a pc, hook on my drive and process all my vbrs.
Thing is: whatever i do, files are always output to 320kbps, whereas they only have a vbr bitrate of eg.182.
I want them to be 192, no point having them at 320.
can somone help me out.
thankyou

MP3 repacker

Reply #382
One of the points of Radiohead using exactly 160 kBit/s was that CBR is supposedly more compatible than VBR. They could just use VBR in the first place instead of creating a pseudo-variable bitrate files in mp3packer.

The constant bitrate must be high enough to fit the largest frame (it's more complex if you remember the bit reservoir). In 182 kBit/s VBR the instantenous bitrate may and usually is significantly higher than 192 kBit/s.

MP3 repacker

Reply #383
ok, which means you get a 256 or a 320kbps file most of the time whan converting vbr to cbr...???
If its normal its cool, but I wanna be shure before doing this to all my library!!! Because it kinda makes files much bigger.
thanx

MP3 repacker

Reply #384
I ran mp3packer on one of my files. It has avg bitrate of 187 kBit/s.

mp3packer.exe -b 256 -z 10.mp3

In this file mp3packer created quite many 320 kBit frames in places where original file had the highest overall bitrate. Whole file was pseudo-variable bitrate with 256 and 320 kbit frames. If you need all frames of equal data length then 320 kBit/s is the only choice on "--preset standard" - like encodes. Lower rate mono files might not need that much, but I don't really know a safe way to find out this without trial and error.

MP3 repacker

Reply #385
OK, thanx! I guess I'm gonna loose some space, but at least I can use my CDJs!
Do you recommend to use -z ???

MP3 repacker

Reply #386
Z gives the smallest possible data length. I used it to test if it's possible to avoid 320 kBit frames at all. For simple conversion to CBR z is of no use since you'll have the max bitrate anyway.

MP3 repacker

Reply #387
I can't make this, I get a long output:

Code: [Select]
r$ make
ocamlopt -c crc.ml
ocamlopt list2.mli
ocamlopt -c list2.ml
ocamlopt expandarray.mli
ocamlopt -c expandarray.ml
ocamlopt c_part.c
ocamlopt -c mp3types.ml
ocamlopt -c pack.ml
ocamlopt -c mp3types.cmx pack.cmx mp3read.ml
File "mp3read.ml", line 164, characters 7-18:
Warning Y: unused variable return_none.
ocamlopt -c expandarray.cmx mp3types.cmx pack.cmx mp3read.cmx mp3info.ml
ocamlopt -c mp3types.cmx pack.cmx mp3framehuffman.ml
ocamlopt -c mp3types.cmx pack.cmx mp3framehuffman.cmx mp3frameutils.ml
ocamlopt -c list2.cmx mp3types.cmx pack.cmx mp3read.cmx mp3framehuffman.cmx mp3frameutils.cmx mp3queue.ml
File "mp3queue.ml", line 326, characters 6-18:
Warning Y: unused variable bitrate_list.
File "mp3queue.ml", line 375, characters 5-18:
Warning Y: unused variable print_bitrate.
File "mp3queue.ml", line 361, characters 5-26:
Warning Y: unused variable update_side_reservoir.
File "mp3queue.ml", line 410, characters 28-3037:
Warning P: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
{side_bits=[|  |]}
File "mp3queue.ml", line 469, characters 18-2462:
Warning P: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
{side_bits=[|  |]}
File "mp3queue.ml", line 527, characters 24-1596:
Warning P: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
{side_bits=[|  |]}
File "mp3queue.ml", line 567, characters 14-1750:
Warning P: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
{side_bits=[|  |]}
ocamlopt -o mp3packer unix.cmxa str.cmxa crc.cmx list2.cmx expandarray.cmx c_part.obj mp3types.cmx pack.cmx mp3read.cmx mp3info.cmx mp3framehuffman.cmx mp3frameutils.cmx mp3queue.cmx mp3packer.ml
/usr/bin/ocamlopt: don't know what to do with c_part.obj.
Usage: ocamlopt <options> <files>
Options are:
  -ffast-math  Inline trigonometric and exponential functions
  -a  Build a library
  -c  Compile only (do not link)
  -cc <comp>  Use <comp> as the C compiler and linker
  -cclib <opt>  Pass option <opt> to the C linker
  -ccopt <opt>  Pass option <opt> to the C compiler and linker
  -compact  Optimize code size rather than speed
  -config  print configuration values and exit
  -dtypes  Save type information in <filename>.annot
  -for-pack <ident>  Generate code that can later be `packed' with
    ocamlopt -pack -o <ident>.cmx
  -i  Print inferred interface
  -I <dir>  Add <dir> to the list of include directories
  -impl <file>  Compile <file> as a .ml file
  -inline <n>  Set aggressiveness of inlining to <n>
  -intf <file>  Compile <file> as a .mli file
  -intf-suffix <file>  Suffix for interface files (default: .mli)
  -intf_suffix <file>  (deprecated) same as -intf-suffix
  -labels  Use commuting label mode
  -linkall  Link all modules, even unused ones
  -noassert  Don't compile assertion checks
  -noautolink  Don't automatically link C libraries specified in .cma files
  -nolabels  Ignore non-optional labels in types
  -nostdlib  do not add standard directory to the list of include directories
  -o <file>  Set output file name to <file>
  -output-obj  Output a C object file instead of an executable
  -p  Compile and link with profiling support for "gprof"
    (not supported on all platforms)
  -pack  Package the given .cmx files into one .cmx
  -pp <command>  Pipe sources through preprocessor <command>
  -principal  Check principality of type inference
  -rectypes  Allow arbitrary recursive types
  -S  Keep intermediate assembly file
  -thread  Generate code that supports the system threads library
  -unsafe  No bounds checking on array and string access
  -v  Print compiler version and standard library location and exit
  -version  Print compiler version and exit
  -verbose  Print calls to external commands
  -w <flags>  Enable or disable warnings according to <flags>:
    C/c enable/disable suspicious comment
    D/d enable/disable deprecated features
    E/e enable/disable fragile match
    F/f enable/disable partially applied function
    L/l enable/disable labels omitted in application
    M/m enable/disable overriden methods
    P/p enable/disable partial match
    S/s enable/disable non-unit statement
    U/u enable/disable unused match case
    V/v enable/disable hidden instance variables
    Y/y enable/disable suspicious unused variables
    Z/z enable/disable all other unused variables
    X/x enable/disable all other warnings
    A/a enable/disable all warnings
    default setting is "Aelz"
  -warn-error <flags>  Treat the warnings of <flags> as errors, if they are
    enabled.  See option -w for the list of flags.
    Default setting is "a" (warnings are not errors)
  -where  Print location of standard library and exit
  -nopervasives  (undocumented)
  -dparsetree  (undocumented)
  -drawlambda  (undocumented)
  -dlambda  (undocumented)
  -dcmm  (undocumented)
  -dsel  (undocumented)
  -dcombine  (undocumented)
  -dlive  (undocumented)
  -dspill  (undocumented)
  -dsplit  (undocumented)
  -dinterf  (undocumented)
  -dprefer  (undocumented)
  -dalloc  (undocumented)
  -dreload  (undocumented)
  -dscheduling  (undocumented)
  -dlinear  (undocumented)
  -dstartup  (undocumented)
  - <file>  Treat <file> as a file name (even if it starts with `-')
  -help  Display this list of options
  --help  Display this list of options
make: *** [mp3packer] Error 2


This is on Ubuntu Gutsy, I installed the ocaml and a few other packages to be on the safe side. I have absolutely no idea about ocaml so I may be doing something idiotic.

MP3 repacker

Reply #388
I can't make this, I get a long output:
...


I really sorry that it is not written in pure perl anymore.
All these troubles with compilers ... :|

MP3 repacker

Reply #389
Code: [Select]
/usr/bin/ocamlopt: don't know what to do with c_part.obj.
I've never tried ocaml, nor did I try to build this project. You may want to find out, if the c_part.c files has been compiled and try to locate the object file. Maybe it was build under a different name and simply renaming it to c_part.obj will do.

 

MP3 repacker

Reply #390
I can't make this, I get a long output:

...

This is on Ubuntu Gutsy, I installed the ocaml and a few other packages to be on the safe side. I have absolutely no idea about ocaml so I may be doing something idiotic.


Run "make OBJ_EXT=.o" instead of just "make"

mp3packer uses a C file for changing priority, which will compile to a .obj file on Windows, but a .o file on everything else. I couldn't find a way to handle both cases automatically, so it has to be specified on the command line.

That should be the only error you run into. Everything else in that code is a warning
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #391

I can't make this, I get a long output:

...

This is on Ubuntu Gutsy, I installed the ocaml and a few other packages to be on the safe side. I have absolutely no idea about ocaml so I may be doing something idiotic.


Run "make OBJ_EXT=.o" instead of just "make"

mp3packer uses a C file for changing priority, which will compile to a .obj file on Windows, but a .o file on everything else. I couldn't find a way to handle both cases automatically, so it has to be specified on the command line.

That should be the only error you run into. Everything else in that code is a warning

Thanks, sorted! I'll investigate the actual running after work.

MP3 repacker

Reply #392
Excuse my boldness to raise my issue...

Even just a "no vs. maybe" statement would be appreciated, regarding an auto-max-cbr switch.

MP3 repacker

Reply #393
Excuse my boldness to raise my issue...

Even just a "no vs. maybe" statement would be appreciated, regarding an auto-max-cbr switch.

Sorry about that. Currently the program is, as you said, only designed for one-pass operation - it would be difficult to add in a two-pass setting. However, I have been thinking of adding support for this once I add multi-threading support. I've just been thinking about how, exactly, to do that. So the answer is yes, but I don't know when.

I may be able to work on it today, actually. I'm supposed to be at work, but there are a lot of fires around San Diego, and it looks like UCSD is closed because of the smoke.  So... I'm home today.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #394

I can't make this, I get a long output:

...

This is on Ubuntu Gutsy, I installed the ocaml and a few other packages to be on the safe side. I have absolutely no idea about ocaml so I may be doing something idiotic.


Run "make OBJ_EXT=.o" instead of just "make"

mp3packer uses a C file for changing priority, which will compile to a .obj file on Windows, but a .o file on everything else. I couldn't find a way to handle both cases automatically, so it has to be specified on the command line.


This might make it less instead of more portable, but if you use the C compiler directly instead of having ocamlopt call the C compiler, you can set the object file name.
change from:
c_part$(OBJ_EXT): c_part.c
        ocamlopt c_part.c

to:
c_part$(OBJ_EXT): c_part.c
        $(CC) $(CFLAGS) -c -o $@ $^

Oh, there's an ocamlopt option -ccopt.  Maybe -ccopt "-o $@" would work.  If you're not familiar with Makefile implicit variables, you could just write it out ("-o c_part$(OBJ_EXT)").  I like writing compact makefiles that use pattern rules, like
Code: [Select]
%.cmx: %.ml
[tab] ocamlopt -c $^
%.$(OBJ_EXT): %.c:
[tab] $(CC) $(CFLAGS) -c -o $@ $^

...
mp3info.cmx: expandarray.cmx mp3types.cmx pack.cmx mp3read.cmx mp3info.ml
crc.cmx: crc.ml
pack.cmx: pack.ml
...


You just tell make about the dependencies, and it puts them all on the command line automatically. (because that's what $^ expands to.)  See the make info page...

Also, I'd suggest removing the --nice option altogether when it's not going to do anything.  Currently the help lies, because --nice does nothing on non-win32.  Or you could look at setpriority(2).
Code: [Select]
#include <sys/time.h>
#include <sys/resource.h>
...
setpriority(PRIO_PROCESS, 0, 10);


Nice job on a neat program.  I had no trouble with it on Ubuntu Gutsy (amd64).

However, what I was really looking for when I found this thread was a program to turn a stereo mp3 into a mono mp3 by dropping one of the channels.  I have some audiobooks which someone foolishly encoded as stereo (and not even joint stereo).  It's only 80kb/s with some noticeable artifacting, so I don't want to transcode it.

I already found earlier in this thread that you were going to add that feature to mp3packer, but it was incompatible with the design of the program.  Do you know of any other program that could do it?  Or would you consider making a separate tool to do it?  Or maybe just not have mp3packer be able to optimize the hell out of an mp3 at the same time its dropping channels.  So making an optimized mp3 would be a two step process.

MP3 repacker

Reply #395
I already found earlier in this thread that you were going to add that feature to mp3packer, but it was incompatible with the design of the program.  Do you know of any other program that could do it?  Or would you consider making a separate tool to do it?  Or maybe just not have mp3packer be able to optimize the hell out of an mp3 at the same time its dropping channels.  So making an optimized mp3 would be a two step process.

It's a feature I have requested some time ago. I also have another question concerning it: can the removal of a channel be done without mp3 repacking (-z)? If no, a separate tool would need to share much functionality with mp3packer. Am I right?

MP3 repacker

Reply #396
omion.. i still need a feature to dump a mp3 in raw form (un-huffman coded) and to pack this raw data later to mp3.. this to help me look for best lossless archivers for mp3 and to ease it development.. so please add it in next version or provide it as seperate tool would be even much better..

there already work in progress on jpeg-lossless compression. it reached min. 17% reduction

http://www.elektronik.htw-aalen.de/packJPG/

so i'm looking a mp3 solution.. please help

MP3 repacker

Reply #397
Hello,
I use the -z switch with mp3packer1.19-180 on mp3 320kbit/s CBR files.
115 197 713 bytes
begins
115 210 236 bytes
So, that makes my MP3 bigger. Do I do something wrong ?

MP3 repacker

Reply #398
I repacked with -z a 320 CBR file that had silence in the beginning with the minimum bitrate set to both auto and 32, but the frame size as reported by winamp says it goes between 320 and 256 kbps.  Why isn't it 32 or at least lower than 256 for silence?

MP3 repacker

Reply #399
Hello,
I use the -z switch with mp3packer1.19-180 on mp3 320kbit/s CBR files.
115 197 713 bytes
begins
115 210 236 bytes
So, that makes my MP3 bigger. Do I do something wrong ?

It looks like the output is larger than the input, but not by much (2KB / 115MB, or 0.01%) There is one case when mp3packer will create larger output files - all the output files have XING tags, so if the input files don't, it will add about 100 bytes to each file. Normally this is overshadowed by the savings in the rest of the files, but if the files are incompressible it will show up as a slight size increase.

I repacked with -z a 320 CBR file that had silence in the beginning with the minimum bitrate set to both auto and 32, but the frame size as reported by winamp says it goes between 320 and 256 kbps.  Why isn't it 32 or at least lower than 256 for silence?

The most likely explanation is that Winamp is not reporting those frames. I don't remember exactly how Winamp displays the frame information, but it could easily skip over reporting the silent frames.

If you want to see how many of each frame there is, run the output file through mp3packer like this: "mp3packer -i outfile.mp3"
If it reports any 32kbps frames, then it's working properly. If not, then it may not be exactly silent there. I've seen noise-shaping algorithms that add a HUGE amount of energy above 20KHz.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2