Hydrogenaudio Forums > MP3 repacker

Hydrogenaudio Forums > Lossy Audio Compression > MP3 > MP3 - Tech

Pages: 1, 2, 3, 4, 5, 6, 7, 8, 9

numbskull

Jul 15 2007, 07:37

QUOTE

I think you may be misunderstanding exactly what mp3packer does. The main thing to realize is that it does not change quality at all; it only changes file size. If you want higher quality MP3 files, re-rip from the source. If you want slightly smaller MP3 files, that's what mp3packer is good at.

I understood the program function, I just don't made myself clear enough

So then using repacker on my 320cbr files will produce smaller files without quality loss at all?
I was worried about the "depending on the LAME version used" described in the program functions.

Another question: if the original files are ripped with other enconder than LAME, repacking them using LAME will have any quality loss/problem ?

pdq

Jul 15 2007, 19:43

QUOTE (numbskull @ Jul 15 2007, 02:37)

There will be no change in quality at all regardless of which encoder/settings had been used. The decoded output will be identical. The "depending on the LAME version" had to do only with how well a file repacks.

As for repacking, LAME has nothing to do with this. The repacking is done entirely by MP3 repacker and nothing else.

Ojay

Jul 15 2007, 19:59

QUOTE (Omion @ Jul 14 2007, 05:27)

The FHG bug deals with the maximum Huffman value. mp3packer does not change these values (and it is generally impossible to do losslessly), it only changes how they are encoded.

The strictly-enforce-iso switch in LAME will lower the maximum amount of data in one frame. However, mp3packer will either not change the amount of data in a frame (without -z), or it will lower it (with -z). This means that a file repacked with -z may have the issue fixed, but it's impossible to always fix it.

That sounds very interesting! mp3packer might "repair" the mp3 decoding issue by using the -z switch. What would be the percentage of "fixing" by using the -z switch? 50%, 90%, 99% ?? That would be interesting to know.

Skylined ;)~

Jul 16 2007, 08:26

Just tried it again and my results

Black Sabbath (2002) Symptom Of The Universe (1970-78)

Using FhG MP3 Encoder 4.0.3 (dbpoweramp Reference) at 320kbps
Using High Quality setting.

Original: 29 files, 348.9 MB, 320.0 kbps
Result: 29 files, 301.0 MB, 275.4 kbps

Hmmm, almost 14% reduction...
this is results using Super-squeeze -z option which is quite slow ;( on a p3 800
with the default settings it actually added 1kb to all the files.

-z
This option makes mp3packer actually decode the audio, do a brute-force search for optimal encoding parameters, then re-encode it. It is quite a bit safer than the old -z switch, but it increases the time to repack the files dramatically. On my computer, a 4-minute file which would get repacked in the blink of an eye would take around 30 seconds with this option enabled.

are you sure it wont change the quality of my files... I am looking at the words :RE-ENCODE:
also, does it werk with mp3pro or 6 channel mp3surround files?

I have a ton of CBR fhg files for I once used all the buggy Fhg encoders until 2005 when i discovered this place... I tried the result all over, in the car, portable, Hifi and headphones and no diff.

But again lovely proggie, keeps my ID tags and APEv2 with RG where applicable.

Ojay

Jul 16 2007, 09:24

QUOTE (Skylined ;)~ @ Jul 16 2007, 09:26)

-z
This option makes mp3packer actually decode the audio, do a brute-force search for optimal encoding parameters, then re-encode it.

(...)

are you sure it wont change the quality of my files... I am looking at the words :RE-ENCODE:
also, does it werk with mp3pro or 6 channel mp3surround files?

Two things:

1.) mp3packer is not lossy! mp3 files are encoded (by encoders) in a 2-pass process, first the audio data are lossily reduced and encoded and then in a second pass the result is being zipped (so to say). The -z switch unzips the audio data (reverses the 2nd pass) but actually does not decode the audio data. Therefore it is actually indeed lossless. mp3packer then re-zips the audio data ( -z means "zipping") with somewhat more brute force methods so that the compression of the zipped mp3 file is finally higher. That's it.

2.) mp3surround files are destroyed by mp3packer! For mp3pro I have no idea but mp3surround is actually a normal stereo mp3 that follows the MPEG-1 specs. To do that it is necessary to store the surround info (call it a "joint surround channel") outside the normal frame data (as "padding"). Padding is (as far as I know) only defined for 44.1kHz mp3 files so mp3surround is only possible for 44.1kHz sampling frequencies.

Now, what is mp3packer doing: it strips off padding from 44.1 kHz mp3 files. As a consequence, any mp3surround info will be removed from the file by mp3packer, you will get a "normal" stereo file instead. Up to now it is not possible for mp3surround files "to survive" an mp3packer pass. So better you do not use mp3packer with mp3surround mp3 files.

Skylined ;)~

Jul 16 2007, 09:43

thanks for the heads up, still what about mp3pro? anyone

Started converting a 40gb drive just now with -z

Ojay

Jul 16 2007, 10:13

QUOTE (Skylined ;)~ @ Jul 16 2007, 10:43)

thanks for the heads up, still what about mp3pro? anyone

make a backup copy of an mp3pro file, then use mp3packer with the file and after that try to play it with the mp3pro player. If it works, then (likely) okay, otherwise stop using mp3packer with mp3pro files.

Report the result here, please.

abasher

Jul 16 2007, 11:23

QUOTE (Skylined ;)~ @ Jul 16 2007, 10:43)

thanks for the heads up, still what about mp3pro? anyone

Started converting a 40gb drive just now with -z

Doesn't using this program on MP3PRO files somewhat defeat it's purpose? MP3 Repacker removes padding, which is almost only available in real high bitrate MP3s. MP3PRO is aimed for very low bitrates, and should be struggling to deliver decent sound -> not pad.

pdq

Jul 16 2007, 11:29

The -z option should potentially provide savings at any bitrate.

MatMaul

Jul 16 2007, 12:21

QUOTE (Omion @ Jul 14 2007, 05:27)

Those are good ideas, but only the encoder can control either of them.

The FHG bug deals with the maximum Huffman value. mp3packer does not change these values (and it is generally impossible to do losslessly), it only changes how they are encoded.

The good news is that if the input file does not suffer from either of these issues, the output file won't either.

thanks for your answer.

but there is something I do not understand.
lame developers said the bitrate increase at V0 in 3.98 version is because of the fhg fix.

I have made some tests on a track at V0 :
3.97 : 254 kbps
3.98 : 264 kbps

and I used mp3packer on those compressed tracks :
3.97 : 254 kbps
3.98 : 256 kbps

so the bitrate increase seems to disappear when I use mp3packer.
are you sure mp3packer doesn't "break" the fhg fix ?

menno

Jul 16 2007, 13:31

QUOTE (MatMaul @ Jul 16 2007, 13:21)

so the bitrate increase seems to disappear when I use mp3packer.
are you sure mp3packer doesn't "break" the fhg fix ?

No, it actually fixes the broken <=3.97 files instead of breaking the 3.98 files.

menno

Jul 16 2007, 13:54

QUOTE (menno @ Jul 16 2007, 14:31)

QUOTE (MatMaul @ Jul 16 2007, 13:21)

so the bitrate increase seems to disappear when I use mp3packer.
are you sure mp3packer doesn't "break" the fhg fix ?

No, it actually fixes the broken <=3.97 files instead of breaking the 3.98 files.

That's with default options...

I tried:

mp3packer -b 320 -R file.mp3

and that creates invalid files (also from LAME 3.98).
The author of this tool should read: http://www.hydrogenaudio.org/forums/index....showtopic=40308

Antonski

Jul 16 2007, 14:39

QUOTE (Ojay @ Jul 16 2007, 11:24)

2.) mp3surround files are destroyed by mp3packer! For mp3pro I have no idea but mp3surround is actually a normal stereo mp3 that follows the MPEG-1 specs. To do that it is necessary to store the surround info (call it a "joint surround channel") outside the normal frame data (as "padding"). Padding is (as far as I know) only defined for 44.1kHz mp3 files so mp3surround is only possible for 44.1kHz sampling frequencies.

QUOTE (Skylined ;)~ @ Jul 16 2007, 11:43)

thanks for the heads up, still what about mp3pro? anyone

I tried with mp3pro, no luck.
In both cases, with and without -z option the result files are smaller:

original : 4184422 100%
repacked : 3949402 94%
repacked,-z : 3863238 92%

However, in both cases the repacked file is not recognized as mp3pro anymore. It is played as mp3 at 22 kHz.
So, if mp3pro rely on some side information (as mentioned for the mp3surround), this info is apparently removed by the repacking.
~

Bruno Monteiro

Jul 16 2007, 19:38

Did a quick test with the -z flag, here are the results:

Original: 1424 MB
Packed: 1338 MB

Ratio: 94,0%

Some albums didn't compress at all (a few KB only), while others got 85% ratio (15% off). While I couldn't find the pattern (encoder, stereo mode, genre), I greatly appreciate this tool.

Great work!!!

The only thing missing (for now) would be dual-core support!

Omion

Jul 17 2007, 03:50

@Antonski:
Yeah. mp3packer will throw away mp3pro info. mp3pro is just mp3 with extra info added, and mp3packer only keeps the part that's actually mp3. The extra info is tagged as garbage and thrown out. I think I mentioned that somewhere earlier in the thread, but it's getting a bit long to read it all...

Bruno Monteiro

Jul 20 2007, 14:41

QUOTE (Omion @ Jul 17 2007, 02:50)

Though some "garbage" is thrown out, I appreciate the LYRICS tag (just started using them) not being discarded. So it only discards not useful metadata? Or has no influence in metadata whatsoever? Thanks!

pdq

Jul 20 2007, 18:00

I believe you will find that actual metadata is preserved. What is thrown away is extra data within the data frames that are not part of the audio data itself.

Ojay

Jul 21 2007, 12:15

QUOTE (pdq @ Jul 20 2007, 19:00)

I believe you will find that actual metadata is preserved. What is thrown away is extra data within the data frames that are not part of the audio data itself.

APEv2 tags will be removed.

numbskull

Jul 23 2007, 02:45

I'm getting very small reduction, almost every frame remains 320

Am I doing something wrong? I'm using "mp3repacker -z"

From 98 mb -> 96 mb from one CD

From 55 mb -> 54 mb from another one

Mangix

Jul 23 2007, 02:50

that's normal. i guess that the mp3(s) were encodec VERY well.

RogerG

Jul 23 2007, 18:56

In the manual you say about the debug option:

QUOTE

It is recommended that you redirect the output to a file, as the information gets quite verbose.

How can this be done? Have I missed the explanation somewhere?

Roger

MedO

Jul 23 2007, 19:21

QUOTE (RogerG @ Jul 23 2007, 19:56)

In the manual you say about the debug option:

QUOTE

It is recommended that you redirect the output to a file, as the information gets quite verbose.

How can this be done? Have I missed the explanation somewhere?

Roger

To redirect stdout to a file, you add ">filename.ext" to your commandline. So in this case, you might write

CODE

mp3packer --debug "all" test.mp3 >debug.txt

Edit: Be careful with this, it can produce text files in the hundreds of megabytes. At least, it did this in my little test just now.

RogerG

Sep 18 2007, 15:27

Hi!
I have a request:
It would be nice if mp3repacker would print the time on Sync errors in addition to the frame number. Then I could easily find that position with my mp3 player and look how the error sounds.

Ciao!

kwanbis

Sep 29 2007, 22:10

Sorry if it was discussed already, but the topic is already too long.

I run mp3recpacker on 2932 files, and it came up bigger! how can that be?

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

0.0 % decrease in size.

0 items failed.

PS: i used -s -t as parameters, and runned it from WinMP3Packer.

MedO

Sep 29 2007, 22:21

QUOTE (kwanbis @ Sep 29 2007, 23:10)

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.

kwanbis

Sep 29 2007, 22:23

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

Nick.C

Sep 29 2007, 22:25

If it's counting upwards from -(2^31) then it would be circa 100MiB less rather than more...

Omion

Sep 30 2007, 06:52

QUOTE (MedO @ Sep 29 2007, 14:21)

QUOTE (kwanbis @ Sep 29 2007, 23:10)

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

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.

kwanbis

Sep 30 2007, 15:55

thanks for the info

LigH

Oct 16 2007, 12:35

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.

Gnerma

Oct 18 2007, 12:32

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

gramouk

Oct 18 2007, 16:54

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

j7n

Oct 18 2007, 17:21

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.

gramouk

Oct 18 2007, 17:46

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

j7n

Oct 18 2007, 19:21

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.

gramouk

Oct 18 2007, 20:06

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

j7n

Oct 18 2007, 20:25

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.

tgoose

Oct 21 2007, 11:42

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

CODE

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.

Antonski

Oct 21 2007, 15:21

QUOTE (tgoose @ Oct 21 2007, 13:42)

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

robert

Oct 21 2007, 15:50

CODE

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

Omion

Oct 21 2007, 19:03

QUOTE (tgoose @ Oct 21 2007, 03:42)

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

tgoose

Oct 22 2007, 09:12

QUOTE (Omion @ Oct 21 2007, 18:03)

QUOTE (tgoose @ Oct 21 2007, 03:42)

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

LigH

Oct 22 2007, 10:17

Excuse my boldness to raise my issue...

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

Omion

Oct 22 2007, 16:44

QUOTE (LigH @ Oct 22 2007, 02:17)

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.

llama peter

Oct 23 2007, 17:15

QUOTE (Omion @ Oct 21 2007, 14:03)

QUOTE (tgoose @ Oct 21 2007, 03:42)

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

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

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

_mik

Oct 24 2007, 12:16

QUOTE (llama peter @ Oct 23 2007, 18:15)

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?

maadjordan

Nov 1 2007, 09:17

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

NightsBird

Nov 6 2007, 13:14

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 ?

DoomzDayz

Nov 6 2007, 13:33

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?

Omion

Nov 9 2007, 00:49

QUOTE (NightsBird @ Nov 6 2007, 05:14)

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.

QUOTE (DoomzDayz @ Nov 6 2007, 05:33)

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.

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.