MP3 repacker

Topic: MP3 repacker (Read 622104 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Reply #75 – 2006-01-20 22:49:15

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

MP3 repacker

Reply #76 – 2006-01-21 10:13:37

Quote

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
[{POST_SNAPBACK}][/a]

My GUI front-end for this script is available here: [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=40780]http://www.hydrogenaudio.org/forums/index....showtopic=40780[/url]
Features batch processing and folder recursion

MP3 repacker

Reply #77 – 2006-01-25 07:59:18

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)

MP3 repacker

Reply #78 – 2006-01-25 22:30:28

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

MP3 repacker

Reply #79 – 2006-01-26 02:04:19

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

Check the thread here

MP3 repacker

Reply #80 – 2006-01-27 04:43:04

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: [Select]

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.

MP3 repacker

Reply #81 – 2006-02-02 15:25:57

Quote

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.
[a href="index.php?act=findpost&pid=360074"][{POST_SNAPBACK}][/a]

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

MP3 repacker

Reply #82 – 2006-02-08 21:01:09

Getting this error:

Code: [Select]

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?

MP3 repacker

Reply #83 – 2006-02-09 06:35:16

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

MP3 repacker

Reply #84 – 2006-02-12 07:10:26

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.

MP3 repacker

Reply #85 – 2006-02-12 07:33:29

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 )

MP3 repacker

Reply #86 – 2006-02-12 08:10:01

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

MP3 repacker

Reply #87 – 2006-02-12 08:51:21

Quote

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

Quote

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.
[a href="index.php?act=findpost&pid=363660"][{POST_SNAPBACK}][/a]

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?

MP3 repacker

Reply #88 – 2006-02-12 09:11:23

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

MP3 repacker

Reply #89 – 2006-02-12 09:34:45

Quote

It seems that mp3packer is chopping the file.
[a href="index.php?act=findpost&pid=363666"][{POST_SNAPBACK}][/a]

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: [Select]

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

MP3 repacker

Reply #90 – 2006-02-12 10:03:14

Quote

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
[{POST_SNAPBACK}][/a]

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: [Select]

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: [Select]

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: [Select]

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 [a href="http://www.softpointer.com/AudioShell.htm]AudioShell 1.1[/url] 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.

MP3 repacker

Reply #91 – 2006-02-12 10:25:31

Quote

Quote
It seems that mp3packer is chopping the file.
[a href="index.php?act=findpost&pid=363666"][{POST_SNAPBACK}][/a]

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: [Select]
#    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.
[a href="index.php?act=findpost&pid=363671"][{POST_SNAPBACK}][/a]

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

MP3 repacker

Reply #92 – 2006-02-12 19:10:28

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

MP3 repacker

Reply #93 – 2006-02-12 20:02:19

Quote

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.
[a href="index.php?act=findpost&pid=363676"][{POST_SNAPBACK}][/a]

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.

MP3 repacker

Reply #94 – 2006-02-12 20:19:56

Quote

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.
[{POST_SNAPBACK}][/a]

see post [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=32379&view=findpost&p=362831]post 83[/url] - FhG

Thanks for looking at this btw

MP3 repacker

Reply #95 – 2006-02-13 08:27:09

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

MP3 repacker

Reply #96 – 2006-02-13 10:16:15

Quote

0.10 out. Just a bugfix. All the recent gripes should be quelched
[a href="index.php?act=findpost&pid=363872"][{POST_SNAPBACK}][/a]

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.

MP3 repacker

Reply #97 – 2006-02-13 13:21:59

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

MP3 repacker

Reply #98 – 2006-02-13 13:28:16

Quote

A feature request:
Rename the original file and use the input file name as output.
[a href="index.php?act=findpost&pid=363922"][{POST_SNAPBACK}][/a]

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

MP3 repacker

Reply #99 – 2006-02-13 19:27:20

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?

Notice