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 626399 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MP3 repacker

Reply #275 –
Mp3Packer does not preserve gapless information from an "Info" frame (Xing frame in constant bitrate files).

MP3 repacker

Reply #276 –
Quote from: j7n on
Mp3Packer does not preserve gapless information from an "Info" frame (Xing frame in constant bitrate files).

I've had no problems with it. I just did a quick CBR128 encode, which registers in Foobar as having the same sample offsets. Which LAME version are you using? Somebody may have screwed up the spec when I wasn't looking. (and an example file would be helpful too)

@Martin F.
Sorry for the delay. I got sick last week and haven't gotten up the energy to do much debugging. However, what you are describing does sound like a bug (as I said, the same errors should be in both files) I'll look into it as soon as the flu gives me the chance to. In the meantime, I'm going to bed
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #277 –
I manully added the gappless information using Foobar 0.9.4.1. I just checked that it didn't create the complete frame, only number of frames, filelength and gapless data. This was the problem, complete Info frames added by Foobar 0.8.3 were preserved.

However, VBR frames containing only the most important information were also created by earlier versions of Mp3DirectCut, and shouldn't be ignored. There is no way Foobar 9 will reindex an mp3 file it detects it as CBR.

MP3 repacker

Reply #278 –
Quote from: j7n on
I manully added the gappless information using Foobar 0.9.4.1. I just checked that it didn't create the complete frame, only number of frames, filelength and gapless data. This was the problem, complete Info frames added by Foobar 0.8.3 were preserved.

However, VBR frames containing only the most important information were also created by earlier versions of Mp3DirectCut, and shouldn't be ignored. There is no way Foobar 9 will reindex an mp3 file it detects it as CBR.

I see the problem now. It's Foobar's fault. 

It looks like Foobar still makes LAME tags without bothering to set the CRC. I already worked around this problem once in 1.07, and I don't want to bend the spec any more than I already have.
The CRC info at the end of a LAME tag is by far the best way of determining whether or not it's a LAME tag or just an XING tag with random garbage at the end. Bad CRC = no LAME tag.

The only exception I made to this was if all the extra LAME info was 0 except for the padding, it would still register as a LAME tag. This was specifically to work around Foobar not updating the frame correctly. However, it looks like now Foobar is smart enough to fill in some other info, but still can't get the CRC right.

In a nutshell, I won't fix this problem, simply because it is not mine to fix. The best way to get it fixed would be to post the issue in Foobar's support forum. The only other reference to the issue is in this post, so it's possible that the Foobar guys don't know about it yet.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #279 –
@Martin F.:

I see the problem now. mp3packer says it keeps the input data on those frames, but in fact it still uses the recompressed data

It actually took me a bit of time trying to find the problem, since I had already fixed it in my working copy of mp3packer  . There is a certain type of bitstream error that is fairly common and all MP3 players seem to deal with it the same. In all the release versions this type of error was fixed nicely, but a warning came up saying the error was not fixed... The next version will simply fix the error and go on repacking.


(I know I'm kind of contradicting myself here: I said before that mp3packer will faithfully reproduce the input errors, but now I'm saying that it will fix those errors. However, the errors that I am fixing here are a small subclass of errors; they are extremely minor, relatively common, and all players deal with them the same. In these cases I think it is wise to simply fix the error, as playback will still be exactly the same.)
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #280 –
Quote
The best way to get it fixed would be to post the issue in Foobar's support forum. The only other reference to the issue is in this post, so it's possible that the Foobar guys don't know about it yet.

Done. But I'm afraid that post will gonna get ignored, since it says between the lines that Fb 0.8 did something better than 0.9 does.

MP3 repacker

Reply #281 –
Thanks for your reply, Omion. Interesting insights in some details of the MP3 format.

So here’s my next question  I noticed mp3packer -z is very fast on some files, for example on this (cough) 34 MB sized file (faster than on a usual file one tenth in size). The files on which I noticed this exceptional speed have a sampling rate of 22050 Hz in common. I don’t know why the sampling rate could have an effect on the compression speed, and the sampling rate and the speed may have no correlation at all  but it’s the only unusual attribute I could find on these files. Do you have an explanation for this?


// Edit: I’m having trouble using mp3packer on Windows 98 with a large file (2.12 GB):

Code: [Select]
D:\Martin>dir
[…]
FFN-CH~1 MP3 2.278.070.131  01.07.06  23:46 ffn-charts.mp3
MP3PAC~1 EXE       647.168  18.02.07  19:13 mp3packer.exe
[…]
         2 Datei(en)         2.278.717.299 Bytes
         4 Verzeichnis(se)       11.211,95 MB frei

D:\Martin>mp3packer -z ffn-charts.mp3
Fatal error: exception Failure("'ffn-charts.mp3' does not exist")

D:\Martin>mp3packer -z ffn-ch~1.mp3
Fatal error: exception Failure("'ffn-ch~1.mp3' does not exist")
FLAC.

MP3 repacker

Reply #282 –
I have a question about the bit reservoir

I was under impression that if I repack a medium bitrate stream with -b 320 parameter, the bit reservoir won't be used for most frames in the stream. I needed to edit a live recording @ 192 kBit/s and followed this path. The output stream contained lots of nulls, but still I was unable to cut the stream without glitches.

How is bit reservoir treated when repackaging mp3 data?
 

MP3 repacker

Reply #283 –
Quote from: Martin F. on
Thanks for your reply, Omion. Interesting insights in some details of the MP3 format.

So here’s my next question  I noticed mp3packer -z is very fast on some files, for example on this (cough) 34 MB sized file (faster than on a usual file one tenth in size). The files on which I noticed this exceptional speed have a sampling rate of 22050 Hz in common. I don’t know why the sampling rate could have an effect on the compression speed, and the sampling rate and the speed may have no correlation at all  but it’s the only unusual attribute I could find on these files. Do you have an explanation for this?

Actually, I seem to remember something about not enabling the -z switch with MPEG2 files (which are what files < 32KHz are) I don't remember why, but I'll see what happens when I re-enable it. I'm at work right now  so I can't do much here, but I'll test it out when I get home.

Quote
// Edit: I’m having trouble using mp3packer on Windows 98 with a large file (2.12 GB):

Code: [Select]
D:\Martin>dir
[…]
FFN-CH~1 MP3 2.278.070.131  01.07.06  23:46 ffn-charts.mp3
MP3PAC~1 EXE       647.168  18.02.07  19:13 mp3packer.exe
[…]
         2 Datei(en)         2.278.717.299 Bytes
         4 Verzeichnis(se)       11.211,95 MB frei

D:\Martin>mp3packer -z ffn-charts.mp3
Fatal error: exception Failure("'ffn-charts.mp3' does not exist")

D:\Martin>mp3packer -z ffn-ch~1.mp3
Fatal error: exception Failure("'ffn-ch~1.mp3' does not exist")

Accessing files larger than 2GB in Win 9x is not straightforward. I don't think OCaml can do it...


Quote from: j7n on
I have a question about the bit reservoir

I was under impression that if I repack a medium bitrate stream with -b 320 parameter, the bit reservoir won't be used for most frames in the stream. I needed to edit a live recording @ 192 kBit/s and followed this path. The output stream contained lots of nulls, but still I was unable to cut the stream without glitches.

How is bit reservoir treated when repackaging mp3 data?


Actually, the way it works is that almost every frame will use the entire bit reservoir. Since almost no frames  use all that space, the next frame will use up as much of the reservoir as possible. What that means is that using "-b 320" will actually lose the most data at the split point.

I have been thinking about trying to minimize the bit reservoir if the program determines that it won't take up any space, but when not using the "-b" switch this will need to cache very large chunks of the file. I'll see if there's a reasonable middle-ground to this.

What I would do to properly cut mp3 files is use pcutmp3, which is designed to avoid any errors. If whatever you use to play them back doesn't support LAME tags, then it won't quite be gapless, but it's as close as mp3s can get.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #284 –
I'm assuming that the program's output is lossless? I'm partially wondering about the -z switch. Is it lossless as well?

thanks
--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 #285 –
It is lossless, with or without the -z switch.  Obviously, if you have any concerns, you could always do a foobar bit-compare to verify the packed mp3 is lossless before tossing the original.  I do that, but then I tend to be a bit overly cautious.  heh

MP3 repacker

Reply #286 –
Why MP3Packer (I use WinMP3Packer 1.13) rewrite 'encoder' field in mp3 files?

MP3 repacker

Reply #287 –
Quote from: nemoW on
Why MP3Packer (I use WinMP3Packer 1.13) rewrite 'encoder' field in mp3 files?

I did a little test with Tag&Rename, and it looks like it will guess the encoder if it is not available in a field anywhere.

LAME will put its version data in the padding info (you have to put something in the padding, so it might as well be useful) If Tag&Rename doesn't see any actual encoder field, it will use this padding data as the encoder.
That's great, except that the padding is exactly what mp3packer gets rid of! So when you put the files through mp3packer, that prevents Tag&Rename from guessing correctly.

So really, it's not rewriting the encoder field, but it is rewriting a hint that Tag&Rename uses to guess at the encoder. If the file stores the encoder data in the tags or in a LAME/XING frame, mp3packer will save it to the output file.



It is odd, though. When mp3packer can't find an encoder field, it will write its own name as the encoder (the header that mp3packer uses requires it) but it looks like Tag&Rename doesn't recognize this; it just assumes Xing for everything...
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #288 –
Quote from: Omion on
I did a little test with Tag&Rename, and it looks like it will guess the encoder if it is not available in a field anywhere.

I am not familiar with mp3 file structure, but it seems like original files (from my 1st post) doesn't have LAME/XING header (here first bytes of file).

Quote
If the file stores the encoder data in the tags or in a LAME/XING frame, mp3packer will save it to the output file.

It is odd, though. When mp3packer can't find an encoder field, it will write its own name as the encoder (the header that mp3packer uses requires it) but it looks like Tag&Rename doesn't recognize this; it just assumes Xing for everything...
Hmm...

I've made aditional tests. Algorthm:
1. Encode small wav file with Lame 3.96.1 to cbr & vbr;
2. Convert with mp3packer cbr>vbr & vbr>cbr;
3. Convert again vbr>cbr & cbr>vbr;
Here interesting results.

MP3 repacker

Reply #289 –
Quote from: nemoW on
I am not familiar with mp3 file structure, but it seems like original files (from my 1st post) doesn't have LAME/XING header (here first bytes of file).

Yeah. That file just goes right into the MP3 data. No headers whatsoever.

Quote
Hmm...

I've made aditional tests. Algorthm:
1. Encode small wav file with Lame 3.96.1 to cbr & vbr;
2. Convert with mp3packer cbr>vbr & vbr>cbr;
3. Convert again vbr>cbr & cbr>vbr;
Here interesting results.

mp3packer uses a slightly different header for CBR and VBR files, although they are functionally the same. It looks like that program is picking up the encoder from the VBR header, but not from the CBR header. But this doesn't explain why the VBR header isn't recognized in the files you mentioned on your first post, though...
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #290 –
I found something interrest. if i convert VBR > CBR > VBR

you got converted VBR file that (a bit)smaller than the original VBR.

maybe you can add an option to "squeeze VBR file" option or something.

MP3 repacker

Reply #291 –
Quote from: buktore on
I found something interrest. if i convert VBR > CBR > VBR

you got converted VBR file that (a bit)smaller than the original VBR.

maybe you can add an option to "squeeze VBR file" option or something.

You may notice that converting VBR > VBR gives the same improvement. The command line will take any MP3 file and repack it to a VBR by default. It looks like with the GUI you have to set "Input Types" to "All" to do the same thing.

How much smaller is the output file, though? It's rare to be able to compress it more than a couple hundred bytes without using the "-z" switch.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #292 –
Ah.. you are right. VBR > VBR  give the same file as VBR > CBR > VBR. Silly me.

and yeah. it get only tiny bit smaller. but i remember i once see that it's smaller enough to not show 0.0% (but how much.. i can't remember)

and thanks for this great tool  i love it.

PS.sorry if my ENG is bad

MP3 repacker

Reply #293 –
1.16 is out! Huzzah!

I basically completely re-wrote the entire thing, which is why it took almost three months. I did fairly extensive regression testing, but there may still have been bugs that slipped through. You are strongly encouraged to check the files before deleting the originals!

Here's what changed:
  • The -z switch now does something with MPEG2 / MPEG2.5 files (should fix j7n's issue)
  • It will now only resync if 3 consecutive frames can be found. Should fix j7n's other issue as well as various other people who have e-mailed me.
  • If the -b switch is used, the bit reservoir is minimized. This behavior may be changed by the -r and -R switches. This addresses j7n's impression. If, for example, a CBR320 file is outputted then the vast majority of its frames will not use the bit reservoir.
  • Major code cleanup to implement all of this. The source looks much better than before...
Also, along the way, I noticed and fixed the following issues:
  • If the first part of a frame is missing, the function which replaced it with nothing was not working correctly.
  • Occasionally the -z switch will output frames which are larger than the input, especially for low-bitrate files. mp3packer now recognizes this condition and will only use the repacked frame if it is smaller. (I should really fix the -z switch to never give a larger frame, but that will take a while)
The -r and -R switches are interesting. mp3packer used to try to minimize frame size, then maximize bit reservoir usage in the frame. This is exactly what you need to make the file as small as possible, but it had a tendency to peg the reservoir when the -b switch was used. I address this issue at the bottom of this post. mp3packer will now figure out the minimum bit reservoir for a frame to use without screwing up the bitrate of any frames after it. However, if the -b switch is not used the analysis may take a lot of memory, and probably won't do anything at all. Therefore, the bit reservoir is only minimized if the -b switch is given. Otherwise it is maximized like before.

The -r switch makes it so that the bitrate reservoir is always minimized, whereas the -R switch will maximize the reservoir (the normal operation for mp3packer before 1.16)

Whew! Done at last!
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #294 –
foo_bitcompare says

Comparing:
csr064_full-load-of-king_elevator-to-the-gallows_5_envelope-infrared_part-1.mp3
csr064_full-load-of-king_elevator-to-the-gallows_5_envelope-infrared_part-1-vbr.mp3
Comparing failed (length mismatch).

Comparing:
csr064_full-load-of-king_elevator-to-the-gallows_7_envelope-infrared_part-3.mp3
csr064_full-load-of-king_elevator-to-the-gallows_7_envelope-infrared_part-3-vbr.mp3
differences found: 3132 sample(s), starting at 71.0415193 second(s), peak: 0.0008336 at 71.0554422 second(s), 1ch

Also happened with the previous version (that reported lots of re- and/or decompression errors). I’ve used the -z switch.

Taken from csr064, author: Full Load of King, CC licensed
FLAC.

MP3 repacker

Reply #295 –
@Martin:

Well, part 1 looks OK with 1.16. I've noticed that in Foobar sometimes you have to force a reload in order for the length to be updated.

Part 3 is indeed doing something odd. I'm trying to figure it out now...
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #296 –
foobar2000 says

Quote
csr064_full-load-of-king_elevator-to-the-gallows_5_envelope-infrared_part-1.mp3
Duration : 4:02.770 (10706159 samples)

csr064_full-load-of-king_elevator-to-the-gallows_5_envelope-infrared_part-1-vbr.mp3
Duration : 4:02.796 (10707311 samples)


A reload doesn’t change it. I opened it in Cool Edit 2000 and it shows an additional (short) silent part at the beginning of the VBR file.
FLAC.

MP3 repacker

Reply #297 –
1.17 is out.

I completely remade the -z switch with the hopes of it getting twice as fast and slightly higher compression. That didn't happen. Instead, I got a -z switch which is 40% slower and slightly higher compression. Most of the time I spent went toward optimizing it (before optimization it went 3x slower  ) Oh well. The -z switch was never meant to be fast. 

The compression improvement (and speed decrease) is mainly evident in low-bitrate encodes. For high bitrates I noticed a whopping 0.03% improvement in the file size versus 1.16.

I also fixed a few bugs related to the -i switch. I hadn't tested it out properly when I released 1.16, so it printed a bunch of garbage and got one of the results wrong. This didn't affect the repacking at all, though.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #298 –
I assume neither of the changes affect WinMP3Packer, so that I just have to replace the .exe?
--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 #299 –
@Omion

Thanks for developing this great tool!

Could you add a option to keep the time stamps of the old mp3 files?