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

MP3 repacker

Reply #325 –
In my tests any files coded with Lame show slight compression even with -z (~4% maximum for some 320CBR). But some high-bitrate CBR files encoded with other tools (iTunes etc.) can be compressed much better (up to 13%).

MP3 repacker

Reply #326 –
Quote from: Omion on
@Jojo:
What program are you using to identify the file? Was this the input or the output file that you checked?

to identify what tags a file contains I use mp3Tag, which I also used for tagging the file.
in terms of identifying what codec has been used I use Audio Identifier and double checked with foobar.
--alt-presets are there for a reason! These other switches DO NOT work better than it, trust me on this.
LAME + Joint Stereo doesn't destroy 'Stereo'

MP3 repacker

Reply #327 –
Quote from: radorn on
If you had read my posts you'd know I already knew and did that, but it gets a bit tiresome after a while you know, so that's one reason I'm asking this.

"Normally I would take extra time to check that the decoded sound is identical to the original after repacking, because my music is important to me (obviously ), but it's pretty time consuming and heavy."
That I said, which you didn't read.
Wow, thanks for the snarky response.  Not only is it unnecessary, but it also makes you sound like a complete jerk since you aren't even in the right.  I read your posts, and saying, "...check that the decoded sound is identical to the original..." does not imply you used foobar2000 to bit-compare the files - it implies you listened to the files, because that's what you do with sound.

In the future it's a good policy not to be pissy to someone who took a moment of time to post a possibly useful reply.  This is especially true when the initial failure is on your end due to not being clear in your posts.

MP3 repacker

Reply #328 –
Thanks Omion, that mostly solves my doubts.

Also, I apologize for littering your program's thread.
I already moved the discussion with that "gib" guy to the private domain.

Quote from: gib on
[...] saying "...check that the decoded sound is identical to the original..." does not imply you used foobar2000 to bit-compare the files - it implies you listened to the files, because that's what you do with sound.

In the future it's a good policy not to be pissy to someone who took a moment of time to post a possibly useful reply.  This is especially true when the initial failure is on your end due to not being clear in your posts.


Whatever, man.

I'll reply to your nonsense privatelly, because we have littered this thread enough so far.

MP3 repacker

Reply #329 –
1.18 is out.

The main difference is the addition of the --nice switch. Use it to change mp3packer's priority.

The --nice switch has a similar range as the Unix "nice" utility. 0 is normal, 19 is idle, and negative numbers are higher priority. The exact mapping from Unix-range numbers to Windows priorities is listed in the mp3packer HTML file.

mp3packer will default to "--nice 10" which will show up as "below normal" in the task manager.

I also fixed some bugs which may or may not have existed.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #330 –
It's refreshing to see this tool being developed so actively, with updates and bug fixes issued at such short intervals.

That said, what about running MP3packer over freeformat MP3s encoded at, say, 325 kbps?  I was wondering: if you're lucky enough to squeeze out enough bits to get them down to 320 kbps (that's just 1.5%, so using the -z switch you should, right?), could this be a nice 'n' clean way to get the highest possible encoding quality for 16 bit stereo MP3s, without breaking compatibility with just about any MP3 software or hardware on the planet?

I have little to no experience with freeformat MP3 files, so it may very well be that I'm daydreaming here.  So if I am, sorry in advance.

Evidently, anyone being that pedantic about audio quality willing to go through the fuss of encoding to freeformat 325 kbps in stead of plain standard CBR 320 kbps, (edit:) without any ABXable improvements, should be referred to any lossless codec of choice.  So my question is purely from a point of view of interest in the format, and in MP3packer.  After all, MP3 having the pile driver ascendancy over any other format it has, for the marginal audience looking for maximum compatibility along with maximum encoding quality, IMHO, this exercise might prove to be worth a small second of attention.


Quote from: sven_Bent on
couldn't this funktion be put into lame ? some thing like -repack
Any news on this?  Worth contacting the LAME developers, if not done so already?

MP3 repacker

Reply #331 –
Quote from: Polar on
It's refreshing to see this tool being developed so actively, with updates and bug fixes issued at such short intervals.

That said, what about running MP3packer over freeformat MP3s encoded at, say, 325 kbps?  I was wondering: if you're lucky enough to squeeze out enough bits to get them down to 320 kbps (that's just 1.5%, so using the -z switch you should, right?), could this be a nice 'n' clean way to get the highest possible encoding quality for 16 bit stereo MP3s, without breaking compatibility with just about any MP3 software or hardware on the planet?

I have little to no experience with freeformat MP3 files, so it may very well be that I'm daydreaming here.  So if I am, sorry in advance.

Evidently, anyone being that pedantic about audio quality willing to go through the fuss of encoding to freeformat 325 kbps in stead of plain standard CBR 320 kbps, (edit:) without any ABXable improvements, should be referred to any lossless codec of choice.  So my question is purely from a point of view of interest in the format, and in MP3packer.  After all, MP3 having the pile driver ascendancy over any other format it has, for the marginal audience looking for maximum compatibility along with maximum encoding quality, IMHO, this exercise might prove to be worth a small second of attention.


It would be possible to make it accept freeformat MP3s, and I looked into it a while ago. The problem is that I don't think anybody uses freeformat at 325kbps (do they?  ), and the possibility of turning freeformat into something useful decreases rapidly above 320kbps.

I had wanted to support converting from allofmp3's 384kbps to 320kbps, since I figured that would be the most popular source of freeformat files. However, in the tests that I did, there were simply too many bits to cram into 320kbps.

I made a program a while ago which can tell the smallest frame size required for a freeformat stream, assuming that the bit reservoir can be used. Run this program on a freeformat mp3 and it will tell you the minimum frame size needed to store all the bits. For 44.1KHz files, if this number is larger than 1009 then the file must be freeformat.

Quote
Quote from: sven_Bent on
couldn't this funktion be put into lame ? some thing like -repack
Any news on this?  Worth contacting the LAME developers, if not done so already?

I don't think it's worth putting into LAME. LAME mp3 files don't get much benefit from repacking, and if you want to convert to CBR, why not call LAME with CBR options...

The -z switch is somewhat useful, but the code required for it is fairly big. Plus, it's all written in OCaml, which is somewhat difficult to integrate into C programs.

All in all, I don't see much benefit from combining mp3packer with any encoders.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #332 –
Quote from: Omion on
It would be possible to make it accept freeformat MP3s, and I looked into it a while ago. The problem is that I don't think anybody uses freeformat at 325kbps (do they?  ) ...
Not yet

Quote from: Omion on
... and the possibility of turning freeformat into something useful decreases rapidly above 320kbps.

I had wanted to support converting from allofmp3's 384kbps to 320kbps, since I figured that would be the most popular source of freeformat files. However, in the tests that I did, there were simply too many bits to cram into 320kbps.
So if I get it right, that means MP3packer currently doesn't support freeformat at all?  I'll agree that it would be of very marginal use anyway.

Quote from: Omion on
I don't think it's worth putting into LAME. LAME mp3 files don't get much benefit from repacking, and if you want to convert to CBR, why not call LAME with CBR options...
Imho, having LAME offer the opportunity to repack any high-bitrate CBR encode out-of-the-box, especially --preset insane, could have its use though.

Edit: fixed quotes.

MP3 repacker

Reply #333 –
Quote from: Omion on
All in all, I don't see much benefit from combining mp3packer with any encoders.

It is known, that mp3 cannot be compressed with any archivers. Only SoundSlimmer can losslessly compress (not repack!) mp3 - partially decode/unpack mp3 and compress unpacked stream with more strong algorithm than mp3 use. But SoundSlimmer is shareware, cmd version absent, no winamp plug-in etc.
Quote
-z
This option makes mp3packer partially decode the audio in the file, optimize the data, then recode it.

Adjacent question: could mp3packer produce partially decoded output (neither mp3, nor wav) that might be compressed with general purpose archivers (and losslessly reverted to mp3)?

Excuse for my bad English.

MP3 repacker

Reply #334 –
Quote from: Polar on
So if I get it right, that means MP3packer currently doesn't support freeformat at all?  I'll agree that it would be of very marginal use anyway.

Right. A freeformat mp3 will pass straight through mp3packer as though it were invalid.

Quote
Imho, having LAME offer the opportunity to repack any high-bitrate CBR encode out-of-the-box, especially --preset insane, could have its use though.

That would make sense, but I don't really think it'd help. I have the feeling that many people who use --preset insane are using it because it is "the highest quality that mp3 can go". If they ended up with a VBR 312kbps file, they'd complain that it was not maxing out the potential of the mp3 file format. Some people would understand it, but they could download the standalone program if they needed. 

Quote from: nemoW on
Adjacent question: could mp3packer produce partially decoded output (neither mp3, nor wav) that might be compressed with general purpose archivers (and losslessly reverted to mp3)?

It's unlikely that a general-purpose archiver would be able to do better with raw, decoded mp3 data than mp3 itself. However, I'll keep it in mind and make a test when I'm less busy.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #335 –
Quote from: Omion on
Quote from: nemoW on

Adjacent question: could mp3packer produce partially decoded output (neither mp3, nor wav) that might be compressed with general purpose archivers (and losslessly reverted to mp3)?

It's unlikely that a general-purpose archiver would be able to do better with raw, decoded mp3 data than mp3 itself. However, I'll keep it in mind and make a test when I'm less busy.


Using arithmetic coding instead of huffman would probably improve the compression ratio noticeably.

MP3 repacker

Reply #336 –
Quote from: Firon on
Quote from: Omion on


Quote from: nemoW on

Adjacent question: could mp3packer produce partially decoded output (neither mp3, nor wav) that might be compressed with general purpose archivers (and losslessly reverted to mp3)?

It's unlikely that a general-purpose archiver would be able to do better with raw, decoded mp3 data than mp3 itself. However, I'll keep it in mind and make a test when I'm less busy.


Using arithmetic coding instead of huffman would probably improve the compression ratio noticeably.

@Firon
It's true that arithmetic coding is more efficient than Huffman coding so it wouldn't hurt to test it for mp3 repacking. However, the more significant improvements in compression ratio usually come from a better "understanding" of the data to be compressed in order to apply special algorithms for certain types of data. (context modeling / context mixing, see also: Wikipedia: PAQ)

@Omion
It should be possible to losslessly compress mp3 better using a more sophisticated algorithm. For comparison just look at the results of the Lossless JPEG compression test.

Rather than implementing de-packing in mp3packer and using another program (for instance a general-purpose archiver) to compress the de-packed mp3, IMO it would be more useful to implement a new context model for mp3 data in an existing program like PAQ.

MP3 repacker

Reply #337 –
And what would be the practical use of the efficiently packed MP3s? Even arithmetic coded JPEGs are not safe for archival because of little support in programs.

MP3 repacker

Reply #338 –
Quote from: j7n on
And what would be the practical use of the efficiently packed MP3s? Even arithmetic coded JPEGs are not safe for archival because of little support in programs.

We're talking about an archiver that could be able to compress mp3's losslessly. Just think of it like zip-/rar-ing your collection of mp3 files in order to save some storage space, with the difference that the hypothetical archiver would compress mp3's much better than zip or rar. These archive files wouldn't be supported by existing mp3 players, of course.

btw. nemoW has provided a link to SoundSlimmer which appears to do exactly what we're discussing here. So it already exists, the question is: when will the first open-source program surface that works even better than that? 

MP3 repacker

Reply #339 –
First of all, I have to say I am very impressed with the performance of the '-z' option! This is particularly true for files that have been recorded on a device doing its own hardware encoding (in this case, an iKey Plus recorder).

The original file: 320kbps
Converted to vbr without -z: 306kbps
Converted to vbr with -z: 165kbps

I have checked the decoded WAV files and did a bit compare on them, and of course the output files are perfectly identical.

That's nearly HALF the size! This leads me to believe the encoder on this portable device isn't really up to scratch! I had a feeling this was the case anyway, and had been using WAV recording on the device for more important applications.

Anyway this means the 'super-squeeze' option will come in handy for compressing mp3s recorded on the device so they can be uploaded/downloaded faster.

MP3 repacker

Reply #340 –
Quote from: psyllium on
The original file: 320kbps
Converted to vbr without -z: 306kbps
Converted to vbr with -z: 165kbps


For the hell of it, I tried squeezing the same file with version 1.16 of mp3packer. It gave me a file of pretty much the same size, I'm not sure whether this is symptomatic of the recording device or its encoding algorithm though. For the 4h30m VBR mp3 file, it took 37 minutes to process in version 1.18 instead of 25 minutes in 1.16. Do you think we could have an option for a 'normal' squeeze (1.16 behaviour), as well as a 'super' squeeze (1.18 behaviour)? No big deal if not, I can use 1.16 still .

Chris.
 

MP3 repacker

Reply #341 –
Quote from: psyllium on
Quote from: psyllium on
The original file: 320kbps
Converted to vbr without -z: 306kbps
Converted to vbr with -z: 165kbps


For the hell of it, I tried squeezing the same file with version 1.16 of mp3packer. It gave me a file of pretty much the same size, I'm not sure whether this is symptomatic of the recording device or its encoding algorithm though. For the 4h30m VBR mp3 file, it took 37 minutes to process in version 1.18 instead of 25 minutes in 1.16. Do you think we could have an option for a 'normal' squeeze (1.16 behaviour), as well as a 'super' squeeze (1.18 behaviour)? No big deal if not, I can use 1.16 still .

Chris.

Blarg. I knew someone would ask for that. For right now, the answer is no, because I changed around a lot of the data types when moving to the new -z switch, so everything would have to be re-written. I was thinking of doing sort of a -z1 -z2 -z3 thing, but that may take a while.

By the way, what were the actual final file sizes?
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #342 –
Quote from: Omion on
Blarg. I knew someone would ask for that. For right now, the answer is no, because I changed around a lot of the data types when moving to the new -z switch, so everything would have to be re-written. I was thinking of doing sort of a -z1 -z2 -z3 thing, but that may take a while.

By the way, what were the actual final file sizes?


I've just recorded a smaller snippet this time around to test it out:
Original file: 1319706 bytes (320kbps CBR)
'mp3packer': 1242296 bytes (301kbps VBR) 94.1%
'mp3packer -z 1.16': 628042 bytes (152kbps VBR) 47.6%
'mp3packer -z 1.18': 627689 bytes (152kbps VBR) 47.6%

As you can see, this recording device is wasting a lot of space! It must be the packet compressing algorithm? But either way the 1.18 -z option doesn't seem to squeeze it that much more. I can provide a sample if you need it.

MP3 repacker

Reply #343 –
Hmmm, I just tried MP3packer with the new LAME3.98b4. The new vbr-code seems to produce a lot of padding (in contrast to LAME3.97, I checked that). I was able to use mp3packer to reduce the bitrate from 231 to 227 (lame parameters: -V0 --vbr-new -b32).

4kbps padding removed with mp3packer :-)

MP3 repacker

Reply #344 –
Quote from: Ojay on
Hmmm, I just tried MP3packer with the new LAME3.98b4. The new vbr-code seems to produce a lot of padding (in contrast to LAME3.97, I checked that). I was able to use mp3packer to reduce the bitrate from 231 to 227 (lame parameters: -V0 --vbr-new -b32).

4kbps padding removed with mp3packer :-)


Yes, I noticed that too. That's pretty strange. I think LAME's vbr routine should be as efficient as possible. Is there any LAME developer here to explain this behaviour?

OT: --vbr-new isn't needed anymore in 3.98. -b32 is also unnecessary.

MP3 repacker

Reply #345 –
it might have something to do with the strict ISO enforcement Lame 3.98 uses
--alt-presets are there for a reason! These other switches DO NOT work better than it, trust me on this.
LAME + Joint Stereo doesn't destroy 'Stereo'

MP3 repacker

Reply #346 –
There is any advantage in converting cbr 192 to vbr (using -preset standard)?

Also, there is no loss depending on LAME version used in the original encoded file or the LAME used in the new file? I'm asking this because I still use LAME 3.90.3 --preset standard, and I'm yet scared to repack my 320kbps files, don't want any quality loss or other kind of problem.

MP3 repacker

Reply #347 –
Quote from: numbskull on
There is any advantage in converting cbr 192 to vbr (using -preset standard)?

If you transcode CBR-192 to --preset standard, there will be quality loss. However, that is not something that mp3packer does.

Quote
Also, there is no loss depending on LAME version used in the original encoded file or the LAME used in the new file? I'm asking this because I still use LAME 3.90.3 --preset standard, and I'm yet scared to repack my 320kbps files, don't want any quality loss or other kind of problem.

There will be no quality loss repacking to CBR-320. However, there will be no quality gain either. Unless you absolutely need CBR, don't repack to CBR-320.

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.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #348 –
hello !

thanks to you Omion for this great tool !

I propose 2 new functionalities :

--avoid-fhgdec-bug to generate mp3 file "compatibles" with the FHG decoder like lame 3.98b4

--strictly-enforce-ISO to do like the switch in lame too 

I don't know if it is possible to do that losslessly, but if it is possible I think it can be useful.

MP3 repacker

Reply #349 –
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 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.

The good news is that if the input file does not suffer from either of these issues, the output file won't either.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2