MP3 repacker Options

[Merlin744]

I was so sad when I first read that pioneer forum last week.

now, I am sooooooo glad this thing works!!

if it could deal with sub-folders inside of the main folder... that would be even better. but now I'm just being picky

[psyllium]

I was so sad when I first read that pioneer forum last week. 

now, I am sooooooo glad this thing works!!

if it could deal with sub-folders inside of the main folder... that would be even better.  but now I'm just being picky

My GUI front-end for this script is available here: http://www.hydrogenaudio.org/forums/index....showtopic=40780
Features batch processing and folder recursion

[Omion]

Just released 0.08. If you don't use the -b switch, you don't care

Basically there was a discrepancy with handling of CBR files. psyllium noted that inputting a 128kbps file with the "-b 128" switch resulted in a VBR file, not the CBR one would expect. The vast majority of the frames were 128kbps, but ~1% were 160.

As a fix, 0.08 now assumes padded frames for valid bitrates, and unpadded frames for invalid ones. For example:
"-b 129" -> UNpadded 160
"-b 128" -> PADDED 128
"-b 127" -> UNpadded 128
"-b 126" -> UNpadded 128
"-b 113" -> UNpadded 128
"-b 112" -> PADDED 112
"-b 111" -> UNpadded 112
etc.

The problem was that the -b switch (before 0.08) assumed unpadded frames, so using "-b 128" REALLY meant "-b 127.706", which opened the door for a 160kbps frame to sneak through (remember that lowering the minimum bitrate tends to raise the maximum bitrate). Now using "-b 128" assumes padded frames, so turns into "-b 128.013". This is enough to guarantee a CBR128 file stays a CBR128 file, but at the expense of a little more wasted space (On the order of 1 bit per frame)

[robert]

padding is only needed for CBR at 44.1, 22.05 or 11.025 kHz. it should be done such that the actual bitrate is always less or equal to the desired bitrate. you may look into the LAME sources or read about it in MPEG-Layer3 Bitstream Syntax and Decoding. You can find that document at Gabriel's "mp3-tech" site: http://www.mp3-tech.org/programmer/docs/96-05.pdf

[psyllium]

A new version, 0.3 beta, of WinMP3Packer has been released which caters for version 0.08 of mp3packer.pl.

Check the thread here

[Omion]

Released 0.09.

Better support for whole directories. Specifically, the -f switch now works on directories, and the -X switch works with single files. Plus, added support for an output directory.

The other addition is the -i switch, which should be of interest to psyllium. It outputs a whole bunch of info, then exits. An example of the output:

CODE

INFO:
 MPEG1 layer 3
 13963 frames
 44100 Hz
 38.28125 frames per second
 364.747755102041 seconds
 6582738 bytes in file (144.37896673351 kbps)
 6582123 bytes in MP3 frames (144.365477959608 kbps)
 6078362 bytes of payload data (133.316505228103 kbps)
 6581030 bytes of MP3 data (144.341505228103 kbps)
 1093 bytes of padding (0.023972731504691 kbps)
 615 bytes outside MP3 frames (0.0134887739024565 kbps)
 Bitrate distribution:
  032: 27,0
  040: 8,0
  048: 7,0
  056: 14,0
  064: 28,0
  080: 187,0
  096: 812,0
  112: 1976,0
  128: 3834,0
  160: 4810,0
  192: 2082,0
  224: 163,0
  256: 15,0
 Smallest bitrate for CBR is 192

The filst few lines should be self-explanatory. All the bitrates are calculated slightly differently:
1st bitrate: bytes in file / second. Includes the tags and non-frame data
2nd: This is the "normal" bitrate, consisting of all the frame data
3rd: The amount of MP3 payload data, without the header, side info, or padding
4th: Payload data + header + side info. This is the theoretical minimum bitrate that mp3packer can pack to.
5th and 6th: How much is used up by padding and non-MP3 data, respectively

Then comes the bitrate distribution: The number of unpadded, padded frames at each bitrate (The example file didn't use padded frames)

Then comes the really interesting part: It calculates the smallest possible CBR bitrate. Like the GUI's approach, it is calculated by iterating through the bitrates and seeing if they will produce a CBR file. However, everything happens in memory and is optimized for just printing out info, so it goes MUCH faster.

[psyllium]

Then comes the really interesting part: It calculates the smallest possible CBR bitrate. Like the GUI's approach, it is calculated by iterating through the bitrates and seeing if they will produce a CBR file. However, everything happens in memory and is optimized for just printing out info, so it goes MUCH faster.

Sweet as dude I'll add support for that when my brain returns from holidays... in a few days I reckon...

[jaybeee]

Getting this error:

CODE

ERROR: Can't run frame location on layer 1 or 2 data at mp3.pm line 1094.

I've tried via both the GUI & commanline and same. Ran a basic command of: 'mp3packer.pl -a -vbr'

Interestingly, the GUI shows this file as being 128kbps, whereas MRQ shows 320kbps FhG.

Any ideas?

This post has been edited by jaybeee: Feb 8 2006, 22:01

[Omion]

That sounds like what Firon's problem on post 55 was. The problem was Unicode tags before the real MP3 data that look like the beginning of an MP1 or MP2 frame.

Make a copy of the file, and strip the tags off the copy (using Foobar or whatever), then try running mp3packer on the copy. If it works, then the problem is a false sync header in the tag. If it still doesn't work, then it's something else

[kevinsham]

I am constantly getting this error message:

Wide character in print at C:\mp3packer/mp3.pm line 866.

The output file does not show correct length in foobar.

[Omion]

Hmmm... that's where the program writes the LAME header. I have a lot of chr(....) statements which could result in a Unicode character slipping by once in a while, although obviously it shouldn't.

What kind of files make this error? Are they massively long? What command line are you using (or are you using psylium's GUI)? Does the file play OK? What if you use Foobar's "fix mp3 header"? (I think that's enough questions for now )

This post has been edited by Omion: Feb 12 2006, 08:37

[UED77]

Omion, I love your program, but I've been having some problems with it.

One is a minor annoyance: assuming a is the original CBR 320kbps mp3 without any ID3 (or other) tags, and b is a VBR by mp3packer 0.09, b - a != 0, which, I assume, it should. I did these operations in Audacity. The differences are minor, and generally inaudible, but it's still not a straight line

The other one is a bigger problem: I tested a CBR 96kbps tag-free mp3 with mp3packer, and got a VBR that had the following properties:

• The copy was 3456 samples "behind" the original file, meaning that every single sample was shifted 3 frames.
• The copy omits last 2304 samples of the original file altogether, even if not using -s. (This also happened with the b-a test above).
• Approximately the first two frames of the copy contain modifications to the actual waveform, distorting the audio data in those first ~50 ms.

I do not know what might cause these problems, as I have removed tags from my input files... So that's why I'm turning to you for help.

Thanks,

UED77

[Omion]

Omion, I love your program, but I've been having some problems with it.

One is a minor annoyance: assuming a is the original CBR 320kbps mp3 without any ID3 (or other) tags, and b is a VBR by mp3packer 0.09, b - a != 0, which, I assume, it should. I did these operations in Audacity. The differences are minor, and generally inaudible, but it's still not a straight line

Does Audacity dither the audio? That would be the most obvious explanation. My program doesn't decode any of the data, so if it messed it up it would probably be a LOT more noticabe than "generally inaudible". It's just about impossible for mp3packer to change the data a little bit. It'll either be perfect, offset by a multiple of 1152, or complete garbage. Try Foobar's "bit-compare files" feature; I know it works (and doesn't dither).

The other one is a bigger problem: I tested a CBR 96kbps tag-free mp3 with mp3packer, and got a VBR that had the following properties:

• The copy was 3456 samples "behind" the original file, meaning that every single sample was shifted 3 frames.
  
• The copy omits last 2304 samples of the original file altogether, even if not using -s. (This also happened with the b-a test above).
  
• Approximately the first two frames of the copy contain modifications to the actual waveform, distorting the audio data in those first ~50 ms.

That's a bit bizarre. Even if the program is misinterpreting the XING tag, it should still only be off by 1152 samples. It sounds like something in the file is confusing my proggie. What version of Perl do you have?

This post has been edited by Omion: Feb 12 2006, 10:00

[kevinsham]

It seems that mp3packer is chopping the file. See the following output for running mp3packer for multiple times.

C:\>mp3packer 5.mp3 5a.mp3
Pre-parsing frame 3836
On frame 3836 of 3836
Output file uses frame sizes from 32 to 320
3836 frames in 1520131 bytes

C:\>mp3packer 5a.mp3 5b.mp3
Pre-parsing frame 3825
On frame 3825 of 3825
Output file uses frame sizes from 32 to 320
3825 frames in 1519171 bytes

C:\>mp3packer 5b.mp3 5c.mp3
Pre-parsing frame 3815
On frame 3815 of 3815
Output file uses frame sizes from 32 to 320
3815 frames in 1518211 bytes

C:\>mp3packer 5c.mp3 5d.mp3
Pre-parsing frame 3805
On frame 3805 of 3805
Output file uses frame sizes from 32 to 320
3805 frames in 1517251 bytes

[Omion]

It seems that mp3packer is chopping the file.

O_O
You're right. Looks like that started on version 0.08. What an odd thing for the program to be doing... testing...

[edit]
WOW. I must have been completely insane when I was working on 0.08.

FIX:
Un-comment line 804 of mp3.pm. Delete the initial "#" character at the beginning of the line:

CODE

#    print OUT mp3::purgeAllFrames(\%framesOut, $padding)

I broke the download link in the first post so nobody else downloads it. I'll release 0.10 as soon as I hammer out the other problems brought to light today. Unfortunately, I am quite tired right now, so I'll work on them in the morning.

This post has been edited by Omion: Feb 12 2006, 10:49

[jaybeee]

That sounds like what Firon's problem on post 55 was. The problem was Unicode tags before the real MP3 data that look like the beginning of an MP1 or MP2 frame.

Make a copy of the file, and strip the tags off the copy (using Foobar or whatever), then try running mp3packer on the copy. If it works, then the problem is a false sync header in the tag. If it still doesn't work, then it's something else

Sorry for not getting back earlier.
Thought I'd let you know the outcome since you'll be looking at v0.10 soon.

If I update any of the tags (actually deleted a couple) in foobar, then it works ok. So, seems it's the same problem as you mentioned. However, when I then run mp3packer I get this:

Command run: mp3packer.pl -M 40 -a -vbr

Output from mp3packer:

CODE

Processing file '1.mp3' (Source bitrate: 320)
Using in-memory processing.
Output file is CBR 320
11147 frames in 11648161 bytes
Finished processing file.

Foobar properties of 1.mp3:

CODE

bitrate = 320
channels = 2
samplerate = 44100
mp3_stereo_mode = joint stereo
codec = MP3
   --------------------
12838511 samples @ 44100Hz
(rounded samples : 12838392)
Length: 4:51.122

Foobar properties of 1-vbr.mp3:

CODE

enc_delay = 0
enc_padding = 0
mp3_accurate_length = yes
bitrate = 320
codec = MP3
channels = 2
samplerate = 44100
mp3_stereo_mode = joint stereo
   --------------------
12840815 samples @ 44100Hz
(rounded samples : 12840744)
Length: 4:51.174

All fine so far, but...
1-vbr.mp3 when put into mp3packer shows the file is 56kbps CBR!
1-vbr.mp3 is displayed as 56kbps CBR by AudioShell 1.1 and the length as 27:43
1-vbr.mp3 is displayed as 56kbps CBR by Mr QuestionMan v0.701 and the length as 27:44
1-vbr.mp3 is displayed as 56kbps CBR by Mp3tag v2.35 and length as 27:52

Now, I'm not bothered about the differences in the lengths that different progs display, but obviously the 27mins'ish time is just not correct. Also, the 56kbps is surely not correct.

Any ideas?

PM me if you want some more details about the file.

[kevinsham]

It seems that mp3packer is chopping the file.

O_O
You're right. Looks like that started on version 0.08. What an odd thing for the program to be doing... testing...

[edit]
WOW. I must have been completely insane when I was working on 0.08.

FIX:
Un-comment line 804 of mp3.pm. Delete the initial "#" character at the beginning of the line:

CODE

#    print OUT mp3::purgeAllFrames(\%framesOut, $padding)

I broke the download link in the first post so nobody else downloads it. I'll release 0.10 as soon as I hammer out the other problems brought to light today. Unfortunately, I am quite tired right now, so I'll work on them in the morning.

This fix has a side effect: the line 866 error is gone too!

[UED77]

Okay, I commented out line 804, like you suggested. The cause of my first problem was probably Audacity's dithering, as foobar2000's bitcompare says the two files's outputs are identical -- albeit of different lengths. Commenting out the line fixes this problem.

As for the second problem issue, commenting out the line seems to fix this too.

Thanks for your help, and keep up the great work!

UED77

[Omion]

Now, I'm not bothered about the differences in the lengths that different progs display, but obviously the 27mins'ish time is just not correct.  Also, the 56kbps is surely not correct.

Any ideas?

PM me if you want some more details about the file.

I think I might know the problem. mp3repacker uses a small frame for the XING header (unless the -b option is given) That space is reserved before the file is written. However, the file that you have was repacked to a CBR file, so the small XING frame says it's CBR. I guess programs see that and think it's actually 56kbps CBR. The problem that I see is that the frame is usually a 64kbps frame, so I don't really see why anything would mistake that as 56kbps.

The timing being off is another effect of the bitrate being completely wrong. 56/320 = 4:51/27:44. Fixing the bitrate will fix the timing.

I think I can make sure that the XING tag only says it's CBR if the initial frame is the same bitrate as the rest of them.


PS. What was the initial encoder? It looks like the encoder didn't use the bit reservoir, and just about completely filled up every frame. It's very rare for my program to output a CBR file without the use of the -b switch.

This post has been edited by Omion: Feb 12 2006, 21:13

[jaybeee]

PS. What was the initial encoder? It looks like the encoder didn't use the bit reservoir, and just about completely filled up every frame. It's very rare for my program to output a CBR file without the use of the -b switch.

see post post 83 - FhG

Thanks for looking at this btw

[Omion]

0.10 out. Just a bugfix. All the recent gripes should be quelched

[jaybeee]

0.10 out. Just a bugfix. All the recent gripes should be quelched

Many thanks Omion.

I reckon that for most peeps using your prog to reduce the size of files and thus make vbr files, it will be done on non-LAME mp3s. Cos most peeps that use LAME will probably use vbr or cbr 192kbps. Thus, the mp3 files might not be created in the nicest way... just like the file that I'm having problems with, and as you said yourself (via PM). Just goes to show how good LAME really is.

[kevinsham]

A feature request:
Rename the original file and use the input file name as output.

[jaybeee]

A feature request:
Rename the original file and use the input file name as output.

Ah yes.
As in: shove '-orig' on the end of the original input file, and thus the resulting output file can have the original's original name (follow me!?).

[MuncherOfSpleens]

Hmm, when using this I get the error message "Can't locate object method 'close' via package 'mp3' (perhaps you forgot to load 'mp3'?) at mp3packer.pl line 171." It will still work when just using the command prompt, but the frontend will cancel the process (or something, it stops and deletes the output file). I was hoping version 0.10 would fix this (I've only had trouble with version 0.9 and now 0.10). Any idea what's wrong?

This post has been edited by MuncherOfSpleens: Feb 13 2006, 20:31