Omion, thanks for the quick update. To tell you the truth though the new mode throws various errors on a lot of the files I've got from other encoders, not just iTunes (1.10 not 1.11, haven't been able to download the new one yet). LAME files seem to work flawlessly across the board of course. Would you be open to me sending you a little love package?

@bukem:
Yeah. My server was having a fit. The mirror link should still have worked, though. Was it down too?

@Gnerma:
Try out 1.11 first. Then send me a few files that still give recompression errors.

Omion, would you be so kind to implement someday one crazy wish of mine: to add (optionally) Lame tag to the output file even if there is no Lame tag in the input file?

@Omion

Yep, main link as also the mirror server were down, but not anymore . Now I can do some test and let you know the results. Greetz.

To confirm: I couldn't access either this morning.

The links are working now

Omion, possibly in the future, can you add an option that outputs an MP3 that does use CRCs. I know, not everyone needs it, but it would be useful.

1.12 is out.

The major change was supposed to be that -z also recompressed short blocks, but it didn't take off a single byte from my 450MiB test suite, so I disabled it.

The only change that made it in was a suppression of warning messages if the error didn't do anything. This was the same error on the reading side as the iTunes error was on the writing side.


That's a solid maybe
I don't think it will be worth it, but I'll look into it. If it's easy, I'll do it.

@Omion

Ave and Congratulations to you Omion! I've just finished mp3packer 1.12 test against my file set, and found no problems so far. Realy Great Job Omion! Keep up good work!!!

I've just tested mp3repacker on some test files using the prescribed syntax, however my files all ended up larger than before.
The original size was 133,031,780 bytes. Final size after repacking was 133,034,692. I didn't use any switches, just "mp3repacker.exe in.mp3 out.mp3"
Got the same results using the GUI.
Here's one of the files for example, it gains 208 bytes from using mp3packer:
http://rapidshare.de/files/37112648/04_Hora.mp3

And the resulting files claim to have a bitrate of 64kbps.

You need to use the -z switch riggits:

Original - 10,347,388
Default - 10,347,596
With -z - 8,812,548

Thanks Gnerma, I just tried that before reading your post
The -z switch also fixes the 64kbps bitrate issue, writing the correct bitrate instead.

@Omion

Hi there! I've found another mp3 track that crashes mp3packer v1.12. And it seems that it's negative padding problem again:

what the heck do you do to your MP3s, bukem?

Ah. That is the one time that mp3packer will make files larger. I think you'll notice that all the files have the same file size increase. (you tested 14 files, right?) This occurs when mp3packer is unable to pack anything, but it still needs to write the XING header.

I don't know what the encoder was, but it didn't write the actual size of the data in each frame, meaning that you need to use the -z switch to recreate each frame. I got a nice 15% decrease when I used the -z switch on your test file.


You did, however, find a minor bug in the XING frame writing. The problem with the bitrate was that there is a 64kbps frame holding the XING header, which says the file is CBR 320. I suppose whatever program you used to get the bitrate info just noticed the 64kbps frame said CBR, therefore it was CBR 64...

Unfortunately, there is no easy way around this. It will only happen if the output file is CBR without the use of the -b switch, which only happens if mp3packer didn't actually do anything (as in your case).

Basically, it won't be fixed. Since it only occurs when programs which don't fully understand the XING header try to get info on an mp3 that couldn't get repacked, it's not high on my priorities.

BTW, which program did you use to get the bitrate info?

Stop breaking my program!

The problem is that the mp3 has two VBR headers: an XING header and a VBRI header. This in itself is not a problem, but both frames say they're simple stereo, whereas all the other frames are joint stereo.

I had fixed the problem with this happening to just XING frames, but mp3packer treats a VBRI frame as standard audio, then throws out the other frames because they have the wrong channel mode.

In this case, the negative padding is actually a symptom, not the cause. While searching for a frame with simple stereo, mp3packer stumbled across a series of bytes that just happened to look like a frame header (it wasn't, though) That series of bytes indicated an offset of 302 bytes, but only 125 bytes were available.

The resultant file starts halfway through the song precisely because of the bogus frame. mp3packer will save everything before the first frame and after the last frame, but will throw out anything between frames. It saw the last frame as being about halfway through the file, and threw out the first half of the song.


What I'll probably do is make a switch to ignore any differences that could indicate invalid frames (like channel configuration and CRC) This will result in a higher level of resilience toward problems like this, at the expence of the possibility of more garbage frames on actually damaged files.

@Omion

Sorry for that, but I realy do love to break mp3packer . THE SWITCH you propose is a good solution I think. It'll solve the irritating bukem problem for sure

Ps. I guess that you could even name it (THE SWITCH) after me .e.g -nomorebukem

Well, I decided to solve your problem a different way than using a new switch: ignore VBRI frames. When a VBRI frame is encountered, it is completely skipped over and its frame settings are not saved to the file. This will make the resultant file ~104 bytes smaller (wow!) and will stop breaking on Bukem's bizarre mp3s.

I probably will also make a switch to be more lenient on the settings, but I'm working on another program right now so it may be a while.

So version 1.13 should work on any files that have the same problem (not too many, I presume...)

PS. I'll keep your naming suggestion in mind when I do implement it!

Great to see this program still being enhanced (or rather after bukem decides to test some files and breaks it! )

Have you had your website for a while now? - I must've missed it...

---

What other program you working on Omion?

I've had my web page since about July. It's got more than just mp3packer on it, though. I also have a bunch of CG pictures that I've made over the years, and some old 64-bit builds of x264.

It's a secret
Actually, it's a program that will do distributed video encoding with x264 over a network. It's pretty hard to get working, but it should be out in a week or two.

I'm (ab)using mp3packer right now to pack CBR MP3s to a higher bitrate, just so I can fool a friend who thinks that "all 128kbps mp3s sound like shit and I can totally hear the diff between 128 and 192". I encoded one to 128kbps using LAME 3.98a6 and packed a copy to 192, then sent him both.

Now to wait for him to listen and see if he thinks the 192 sounds better...

Let's just hope that he doesn't read this.

I have (finally) released a new version of WinMP3Packer to handle some of the extra options in mp3packer.exe. The thread is here.

@Omion

You know, I love the program since the first 0.x versions
I enjoy a lot the new -z switch but these days I found a file that generated a bunch of warnings (there were no warnings without -z switch).



This file was reportad as Xing(old) by EncSpot.
The -i switch produced the following output:


Anyhow, a new vbr file was created and it seemed to be OK (checked again with -i switch).
I don't know if it's safe to use the new file though.
Well, I could live with it, it is just one file, but if you are interesting what caused the problems I could send it to you.
From my experience I know that the (ex)perl programmers don't have a rest untill the last issue is fixed .

Cheers
Tony

Heh. Keep us informed. This sounds interesting

Well, to tell the truth, all those warnings are fairly benign. I've been thinking about removing it altogether, because they don't really mean much.

If you get any warnings that say "WARNING: error recompressing frame x" then that means mp3packer did something bad. The bitstream errors just mean that the encoder cut a few too many corners.

In each frame of an MP3, there are 576 frequency bands, but some encoders go a little overboard and encode 578. In 1.12 I supressed the warnings when those extra bands were 0, but some encoders actually want to put data up there... all the decoders just throw the last 2 out, and mp3packer does too, but it outputs a warning each time it happens.

Quieting the error is on my list for the next version, but my video encoding proggie comes first.

^^ rather than "Quieting the errors" how about turning "off" the display of them by default, but allowing a user, via a switch, to have them turned on?

The mp3packer is really good, but could you add a small feature to it ? It would be great to convert mp3 from stereo to mono, by removing one channel (either left or right for dual channel, side channel for mid side stereo, or maybe also removing the panning info from itensity stereo frames).

I have a bunch of badly recorded mp3s. They are m/s stereo CBR, but one channel is silent, so i guess the side channel equals +/-mid channel. It is very annoying to hear them on stereo headphones. I would like to convert them to mono losslessly (not counting loosing the side channel , but that's my point).

Thanks in advance,
mik

That would work OK for dual-channel or simple stereo, but joint stereo would be quite a bit harder. The problem is that joint stereo means that each frame can be encoded in either L/R stereo or M/S stereo. I could easily take out the first channel in every frame, but that would switch between taking out the side channel and taking out the right channel.

Depending on how the scalefactors work, I may be able to mix the left and right channels perfectly (*), but that depends on me figuring out scalefactors

I'll probably be able to look into it soon, as I think I can get my other program out the door sometime in the very near future.

(*) obviously, this wouldn't be lossless at all, but I should be able to make it mathematically perfect ((L+R)/2)

My files (although they are joint stereo) have all frames indicated as ss (in EncSpot), so they are L/R stereo (if I understand correctly EncSpot's details window). They were recorded using an iRiver from a mic amplifier.


Hmm, I've heard some people saying it's impossible

On the other side, you could also add a possibility to extract L or R channel from M/S stereo frames using (M+S) or (M-S) formula.

In my case I would prefer extracting L or R, because the other channel is silent. Doing (L+R)/2 will mix noise from the silent channel and will lower overall signal level (because of dividing by 2).

mik

I just finished looking at the scalefactor code and... yup. Impossible. If scalefactors went in powers of 2 it would be OK, but it looks like they go in powers of 2^0.25, which makes it impossible for just about every case.


For joint stereo, that would be exactly as impossible as mixing stereo to mono. For simple stereo, though, it should be quite easy. But are your files joint stereo? I don't want to make something that wouldn't be of any use at all

(Note that when I say impossible, I mean it will be impossible to do it losslessly. It is, of course, quite easy to do in an audio editor)

, but 2 = (2^0.25)^4, isn't it?

You could still do the thing I requested at the beginning, i.e. keep L or R for L/R frames (selected via a cmdline switch), or M for M/S frames. This should sound ok, if a mono source was recorded to both channels (M=L=R=(L+R)/2).


As I already said, my files are marked as joint stereo, but 100% frames are ss in EncSpot (= L/R, I guess).

mik

Although you're right, it doesn't quite work, unfortunately.

Here's why:
The only way to mix the two channels would be to change the scalefactors so that they're equal, then combine the scaled samples.
The change in the scalefactor (δ) is always going to be the inverse of the change in the scaled sample in order for them to be equal in the end. real_sample = scalefactor * scaled_sample = (scalefactor / δ) * (scaled_sample * δ)
Since the scaled sample must be an integer, δ must also be an integer, which means it cannot go in small enough steps to make it accurate.

Here's a little example:
Let's say the left channel has scalefactor 2, and the right channel has scalefactor 2^0.5 (1.414..., an irrational number). We need to find integers δL and δR such that:
2 * δL = 2^0.5 * δR
δL and δR will always be integers, so 2 * δL is an integer.
But 2^0.5 is irrational, and an integer times an irrational number is always irrational.
So we have:
{some integer} = {some irrational number}
which will never happen.
Therefore, in order to work, δL and δR cannot be constrained to integers, meaning that the output sample will not be an integer, which it must be in order to be stored.

I hope that made some sense...


If it's a mono source, it will sound great. For a stereo source it may sound highly odd. But it looks like, in your case at least, this will work.


Great. Then there will be no problem. I'll get to work on it when I find the time

Requantization is always required when mixing channels regardless of how the scalefactors are because of the non-linear quantizer MP3 uses.

Heh. I hadn't even looked that far into the decoding, but you're right that that makes completely impossible anyway.

I have another question: is there a possibility to change volume of a whole mp3 losslessly? I know I can use replaygain, but it works with only a few programs. Maybe scalefactors will do the thing, or something like global gain? If so, mp3packer could have such a feature .

mik

@mik:

I guess that what are you looking for is simply mp3gain

Yeah, you're right, bukem. Thanks .

mik

Well, it looks like the "extract first channel" won't be done any time soon. There are just too many places where I assume that the input type is the same as the output type (especially with regard to the number of channels) Sorry!

Omion, In my foobar2000 playlist view, I set the "Technical" column to show codec, bitrate and tagtype, as well as whether or not the MP3 uses "Accurate Length" info:

Now, on one of my old albums I had a single track that was damaged; I replaced it with an MP3 from an alternate source, and used mp3packer to match the CBR bitrate to the rest of the album (no technical advantage... I just liked seeing a consistent bitrate through the album, without one track jumping up and down saying, "I'm different!").

The old album had been encoded without any sort of "Accurate Length" tag, but the repacked version is showing its presence. I've already tested by repacking the entire album, and the "◦" indicator appears consistently where it was not present before, so I'm assuming mp3packer is simply adding a L.A.M.E. tag and indicating the possibility of a sample offset without currently calculating one. Correct?

If this is the case, would it be possible to add the capability (or add a switch, if need be) to parse silence within the MP3 file and guesstimate to appropriate sample offset - as iTunes apparently now attempts to do - so that this pseudo-"Accurate Length" info could be doing something useful? Please?

- M.

That is weird.

I did a test and, sure enough, Foobar flags it as "accurate" What I don't understand is where Foobar gets that idea...

mp3packer will only write the delay data if it finds it in the input file. (It uses an XING tag by default, and only uses a LAME tag if one was found in the input)

Foobar is doing something odd. If it actually did have sample-accurate length, the tags <ENC_DELAY> and <ENC_PADDING> would show up in the properties, right above <MP3_ACCURATE_LENGTH>. On the mp3packer output, <MP3_ACCURATE_LENGTH> is set, but neither <ENC_DELAY> nor <ENC_PADDING> are.

I think Foobar has a different idea of "accurate length" than either of us do. Perhaps "accurate length" means that the number of mp3 samples is known without reading the whole file?

I think you can change your code to something like:

That should get you the info you want.

Your idea to add the padding data would be very handy, but it would require a lot of work on my part. I would need to make an entire mp3 decoder in order to get at the actual samples. Currently, mp3packer only dequantizes the frequency coefficients, and that was hard enough to get working!

Yes, weird.

The code change you suggested does indeed accomplish what I was attempting, and in a slightly more elegant manner, by eliminating those false positives. Thank you.

What would be the feasibility of parsing the frame/sample info to an existing, open-source decoder? Would that even be a possible solution, and if so, worth pursuing? Admittedly, the best solution to accomplish "Accurate Length"-style gapless performance will always be a clean encode, although I can imagine situations when that might not be as easily accomplished as one might desire.

- M.

This is a quite useful tool. But why do you fill the unused space with the title of your proggie? It is hard to visualize silent frames after running the file through Mp3Repacker.

Eh... I fill it with the title because I have to fill it with something. Most people don't see it, and sometimes there's nowhere else to put the name of the program.

Is it that much harder to visualize it as silence than a string of nulls? Every hex editor that I've run across has an ASCII view right next to it. More "mp3packer1.13-145" means more silent

I visualize it this way.. Repeated bytes of any value, no matter 0x00 or 0x55 = silence. Otherwise it's a signal. BTW, never mind: already replaced both strings in the exe.

How can one be sure that Mp3Repacker is lossless? I am using it with the -z option (so that it actually does something).

- Could I assume everything went right if there were no error msgs?

do a bit comparison with the original file. If it's the same, it was lossless.

Heh. I didn't think of that
Note, however, that the version string is also used in the help output. Not really a big deal, though.


I have the best success with Foobar's "bit compare files" option.
[edit: Firon beat me to it. I should really try to take less than 14 hours to write my responses ]


Probably. I haven't found any losses with valid input files, but that doesn't mean that there are no problems. If you have any concerns, run the files through Foobar. Then post here if any files don't give warnings but fail Foobar's test.

I got an error …


The file can be downloaded using this torrent: http://www.legaltorrents.com/bit/dimitris-...hythmos.torrent (µTorrent lets you download individual files)
Is that an error in mp3packer or in the file?

Anyway, great program, thanks

It is most likely an error in the file which is triggering an error in the program. But the program shouldn't give that error at all. I'll see what's up.

[edit: Actually, that error means that the -z option failed, so it was not used for that frame. The files are still bit-identical, though]

@Omion:
I've spotted several times the same kind of warnings that Martin F. pointed out in his post but because the bitcompare doesn't show any differences I didn't reported it to you. By the way - I've processed don't-know-how-many-in-fact mp3 files since last time we spoke without any problems so far

Edit: don't-know-how-many-in-fact ~ circa 5000 files

Yeah, that message is really not an issue. The it's really just a warning, not an error (even though it says "error" in it)

I changed my working version to have less alarming warning messages (especially that one), but I decided that it wasn't worth it to actually release an update.

As you have a lot of practical experience: can you report about your results please?
What encoder did you use which way before repacking? What is the average filesize improvement?

Background for my question: I know the repacker brought an essential improvement for Lame 3.97b1 encoded files but after bit reservoir was reinstuituted with b2 I had the impression that the repacker isn't that useful as it was before. However I see the repacker is still being used actively, so I'd like to learn about its current usage and properties.