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

MP3 repacker

Reply #225 –
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

MP3 repacker

Reply #226 –
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)
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #227 –
Quote from: Omion on
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.

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.

Quote from: Omion on
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

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

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

MP3 repacker

Reply #228 –
Quote from: _mik on
Hmm, I've heard some people saying it's impossible

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.

Quote
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

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)
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2
 

MP3 repacker

Reply #229 –
Quote from: Omion on
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.

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

Quote from: Omion on
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

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

mik

MP3 repacker

Reply #230 –
Quote from: _mik on
Quote from: Omion on
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.

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

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

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

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.

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

mik

Great. Then there will be no problem. I'll get to work on it when I find the time
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

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

MP3 repacker

Reply #232 –
Heh. I hadn't even looked that far into the decoding, but you're right that that makes completely impossible anyway.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #233 –
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

MP3 repacker

Reply #234 –
@mik:

I guess that what are you looking for is simply mp3gain

MP3 repacker

Reply #235 –
Yeah, you're right, bukem. Thanks .

mik

MP3 repacker

Reply #236 –
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!
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #237 –
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:
Code: [Select]
$if($info(mp3_accurate_length),◦ )%codec% '[' %bitrate% kbps [· $info(tagtype)]']'

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.

MP3 repacker

Reply #238 –
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:
Code: [Select]
$if($and($info(enc_delay),$info(enc_padding)),◦ )

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!
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #239 –
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.

MP3 repacker

Reply #240 –
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.

MP3 repacker

Reply #241 –
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
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #242 –
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?

MP3 repacker

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

MP3 repacker

Reply #244 –
Quote from: j7n on
BTW, never mind: already replaced both strings in the exe.

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.

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

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  ]

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

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.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #245 –
I got an error …

Quote
mp3packer.exe -z "C:\Dokumente und Einstellungen\Martin\Desktop\dimitris-08-not-human.mp3"

*** 'C:/Dokumente und Einstellungen/Martin/Desktop/dimitris-08-not-human.mp3' ->
'C:/Dokumente und Einstellungen/Martin/Desktop/dimitris-08-not-human-vbr.mp3'
WARNING: error recompressing frame 10: Invalid_argument(index out of bounds)
100% done with 15174 frames

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

MP3 repacker

Reply #246 –
Quote from: Martin F. on
Is that an error in mp3packer or in the file?

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]
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #247 –
@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

MP3 repacker

Reply #248 –
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.
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2

MP3 repacker

Reply #249 –
Quote from: bukem on
... I've processed don't-know-how-many-in-fact mp3 files since last time we spoke without any problems so far  ...

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.
lame3995o -Q1.7 --lowpass 17