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.

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)

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

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 data2nd: This is the "normal" bitrate, consisting of all the frame data3rd: The amount of MP3 payload data, without the header, side info, or padding4th: 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.

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

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

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 )

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.

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.

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?

O_OYou'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.

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:

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:431-vbr.mp3 is displayed as 56kbps CBR by Mr QuestionMan v0.701 and the length as 27:441-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.

O_OYou'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.

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.

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.

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.

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.

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?