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 599682 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

MP3 repacker

Reply #400 –
Quote from: Omion on
Quote from: DoomzDayz on

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"



Or you can use EncSpot to see the bitrate distribution, if you prefer GUI applications.

~

MP3 repacker

Reply #401 –
I like mp3packer so far (of course, I am using it at least 1x -2x weekly)

but there is one thing I would suggest to implement:

mp3Surround data are stored in the padding data of normal stereo mp3 files. Using mp3packer always removes the mp3Surround data, leaving a bare stereo mp3 behind. Is it possible for mp3packer not to touch the surround data?

Or if that isn't possible - can you implement checks for mp3Surround data structures, followed by a warning that the user is destroying these structures by continuing?

Thanks

MP3 repacker

Reply #402 –
I'll look into it if you can find me something that says what to look for. That's the problem with mp3pro and mp3 surround - they aren't free standards so there isn't a nice, concise spec sheet to base my implementation off of. There are some free surround implementations, but that would require reverse-engineering the format, which I'm not in the mood for.

Actually, now that I think of it, there may not be an easy way to keep surround data in the current incarnation of mp3packer. I based the whole program off of removing the padding, so I would have to change the entire pipeline around to keep it from beginning to end. Detection, however, should be relatively easy.

[edit] Now that I've looked around, I may have found an open-source mp3-surround detector, so I'll look into using it as a base for my own. [/edit]
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #403 –
I tried to make a build with the 1.19 source with Ubuntu and it didn't work.  The last one I made is 1.16 and it works fine.  I tried both "make" or "make mp3packer" with no luck.  I'm not a programmer at all.  Just a directions follower.  It's a very useful program and 1.16 works fine for me, but I like to update every so often.  Any help is appreciated.

MP3 repacker

Reply #404 –
Quote from: cbrigstocke on
I tried to make a build with the 1.19 source with Ubuntu and it didn't work.  The last one I made is 1.16 and it works fine.  I tried both "make" or "make mp3packer" with no luck.  I'm not a programmer at all.  Just a directions follower.  It's a very useful program and 1.16 works fine for me, but I like to update every so often.  Any help is appreciated.

Use this line instead:
Code: [Select]
make OBJ_EXT=.o

The reason it worked with 1.16 is that I didn't have any C code. 1.19 has C code in a few places for the priority changing code, and unfortunately the output files have a different extension between Windows and everything else.

To respond (very late) to llama peter:
The problem with forcing the extensions is that the object files have to be linked with OCaml, which only knows about one type of object extension. For example, the Linux OCaml knows that a C object is *.o, and doesn't know how to handle *.obj files. The Windows OCaml knows that a C object is *.obj, and doesn't know how to handle *.o files...


PS. The really annoying thing is that the priority-changing code is only used in Windows. In Linux it is compiled to a no-op, then the OCaml-native priority-changing code is used instead. The reason it's in there is that OCaml doesn't know which OS it's running under until the program runs, so the code has to be the same in every case.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #405 –
Thanks again!  Works like a charm.

MP3 repacker

Reply #406 –
is it possible to convert (loseless) mono format to stereo format (ms stereo = 0%, no audio data changed)?

MP3 repacker

Reply #407 –
Quote from: ZinCh on
is it possible to convert (loseless) mono format to stereo format (ms stereo = 0%, no audio data changed)?

If you convert it to 0% ms then the size will double. If instead you convert it to 100% ms then the size will not increase and the quality will be identical.

MP3 repacker

Reply #408 –
Quote from: pdq on
Quote from: ZinCh on

is it possible to convert (loseless) mono format to stereo format (ms stereo = 0%, no audio data changed)?

If you convert it to 0% ms then the size will double. If instead you convert it to 100% ms then the size will not increase and the quality will be identical.

sorry, my mistake, i mean what you say  so is it possible to do that using mp3 repacker?

MP3 repacker

Reply #409 –
Quote from: ZinCh on
Quote from: pdq on
Quote from: ZinCh on
is it possible to convert (loseless) mono format to stereo format (ms stereo = 0%, no audio data changed)?
If you convert it to 0% ms then the size will double. If instead you convert it to 100% ms then the size will not increase and the quality will be identical.
sorry, my mistake, i mean what you say  so is it possible to do that using mp3 repacker?

No, that kind of conversion is not possible using mp3packer.

Btw. a question very similar to yours has been discussed already in this thread:
Lossless mono to JS conversion

MP3 repacker

Reply #410 –
Hello, Omion!

I just downloaded the source code and I'm surprised to find code to parse all the side- and main-data parts (scalefacs, huffman bits). Exactly why do you need all of this? Isn't "main_data_beg" and all the "part_2_3_length" values good enough to determine the beginning and count of the maindata bits? (count = sum over all part_2_3_length values)

Cheers,
SG

MP3 repacker

Reply #411 –
Quote from: SebastianG on
Hello, Omion!

I just downloaded the source code and I'm surprised to find code to parse all the side- and main-data parts (scalefacs, huffman bits). Exactly why do you need all of this? Isn't "main_data_beg" and all the "part_2_3_length" values good enough to determine the beginning and count of the maindata bits? (count = sum over all part_2_3_length values)

Cheers,
SG

It is not needed for normal operation, but the -z switch needs to actually decode the data, so most of the side info is needed. I don't use the global gain or the "pre" flag, but since I was recreating the entire side-info from my data structure it made more sense to parse them as well.

I was planning to use the scalefactors themselves to see if there was any way to optimize them, but it turned out to be useless. I didn't bother to get rid of the parsing code, and the overhead is minimal (much smaller than the time it takes to brute-force Huffman tables)

This is all assuming you're looking at mp3frameutils.ml. That's where the decoding/recoding of the mp3 data takes place, and where most of that data is actually needed. If you don't use the -z switch, this whole file is not used. In all of the other locations the side_info is represented by main_data_begin, length of each granule (in bits), and length of all granules (in bytes). Or, at least it should be... I haven't looked at the code in a while.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #412 –
Anyone tried to build this on OSX?

MP3 repacker

Reply #413 –
Hey, I whipped together an OSX wrapper for this using Platypus. It's pretty primitive, but it works!

Drag 1 or more mp3 files onto the icon, and it should crank away... don't think it works for folders... it uses a perl wrapper that is easy to modify if anyone out there actually knows what they're doing (I've never touched perl before this :-p)

You can find it here: http://apoctrack.com/mp3packerX/

NOTE: it requires DARWINE available here, installed in your applications folder (modify the script if it's elsewhere, or whatever)

p.s. (I tried compiling the ocaml source, but got some weird errors, so this was my Plan B)

p.p.s. Woops, I think funky characters in filenames break it... (yeah, it seems to be apostrophes) help?

here's a one line BASH script to write the new -vbr.mp3 files over their originals
Code: [Select]
for i in *-vbr.mp3; do j=`echo $i | sed 's/-vbr.mp3/.mp3/g'`; mv "$i" "$j"; done

MP3 repacker

Reply #414 –
(Thanks for the great piece of software. I've been waiting for something like it for quite some time, but:)
I've run the thing on a bunch of files (shaving off more than 20 percent with some of them - impressive! -) and now the modified files seem to have different content: Pasting the inverted signal of the second file over the first shows some altered samples (the difference is just one step on the 16-bit-dynamic-range each time, most of the time several together in a small group, with about 40 such groups per minute, most of the time about 1.7 seconds apart).
foobar's bit comparison feature even reports different durations (like
Code: [Select]
Comparing failed (length mismatch : 4:24.740862 vs 4:24.778209, 11675072 vs 11676719 samples).
).

While this should not be audible I still wonder where it comes from...

MP3 repacker

Reply #415 –
The differences in the lengths may be because Foobar is more lenient with LAME/XING headers, whereas mp3packer is tighter. The number of samples (1647) is about right for that. I've seen that happen a lot with not-quite-compliant headers.

The actual differences in the files is a bit odd, and may be because of how the file was encoded. I'll look into it.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #416 –
Quote from: Speckmade on
the difference is just one step on the 16-bit-dynamic-range each time

That's probably just dithering. Try decoding the same file twice and compare. You'll probably see these "differences" there too.

MP3 repacker

Reply #418 –
I have a mp3 file here with 31 frames. The first 5 don't have CRC's, all the rest does. When mp3repacker is done with this file it reports it only processed 5 frames. But the output has the right amount of frames.

MP3 repacker

Reply #419 –
Quote from: menno on
I have a mp3 file here with 31 frames. The first 5 don't have CRC's, all the rest does. When mp3repacker is done with this file it reports it only processed 5 frames. But the output has the right amount of frames.

That's because, by default, it keeps all of the stuff after the last frame. Since mp3packer only recognizes 5 frames, it repacks those and copies everything after it, which includes all the other frames.

This can result in a problem if the 6th frame depends on something in the 5th frame. mp3packer doesn't worry about it in this case since it doesn't think there is a 6th frame, but it can result in the 6th frame's data being corrupted. However, if the file is a result of splicing two MP3s together (probably how it was made) then you won't have this problem.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #420 –
This software is great! Prior to finding this, I thought the only solution was to re-encode the files (I know, not good!).

But I have one issue, and I searched and couldn't find an answer. A lot of the VBR files I am loading into this program (to convert to 320CBR) are coming up as 128CBR files, not VBR. The program thinks they are CBR files, when they definitely are not (they are mostly V2 or V0). Even the "force" setting doesn't convert these files, the program skips them. I cannot figure out a way around this. Can someone help me?
 

MP3 repacker

Reply #421 –
Quote from: Omion on
Quote from: menno on

I have a mp3 file here with 31 frames. The first 5 don't have CRC's, all the rest does. When mp3repacker is done with this file it reports it only processed 5 frames. But the output has the right amount of frames.

That's because, by default, it keeps all of the stuff after the last frame. Since mp3packer only recognizes 5 frames, it repacks those and copies everything after it, which includes all the other frames.

This can result in a problem if the 6th frame depends on something in the 5th frame. mp3packer doesn't worry about it in this case since it doesn't think there is a 6th frame, but it can result in the 6th frame's data being corrupted. However, if the file is a result of splicing two MP3s together (probably how it was made) then you won't have this problem.


No it's not how it was made, it's actually one of the MPEG reference files for testing decoder conformance. Also the standard simply allows changing CRC on or off from frame to frame.

MP3 repacker

Reply #422 –
Thanks a lot apoc_metal !!!

Thing is your link is "not found", I found mp3packerx Here .

Finally a Mac version!  But I don't have an Intel based mac, is there any way you could whip out a nice little powerpc version for all us still on G4....

Thanx

MP3 repacker

Reply #423 –
Quote from: menno on
No it's not how it was made, it's actually one of the MPEG reference files for testing decoder conformance. Also the standard simply allows changing CRC on or off from frame to frame.


Actually, when I just tried to change the behavior of mp3packer, I just noticed that it should already accept different CRCs per frame, even though it doesn't... I'll see why.

I'm looking around on my conformance files here, and I assume you are talking about layer3/hecommon.bit? I'll do some tests on those files.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #424 –
After looking through the conformance files, I decided to let changes in CRC, copyright, and emphasis through. Version 1.20 should now repack Menno's entire file.

I thought I had already turned off the requirement for CRC, but it looks like that was only between a frame determined to be an XING/LAME frame and the next frame. Oh well. It's off for all frames now.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2