...and when checked with mr questionman, make it look like ripped with a different method? i'm asking this cuz i downloaded some files off the net, scanned with mr questionman and it said:

lame 3.90.3, method -alt preset extreme.

However, those were metal songs and bitrates were kinda low (180-185 kbps). After some weeks i bought the same cd and made mp3 with the same method and encoder, but this time i got totally higher bitrates (260-275 kbps).

So i'm wondering this: is it possible to modify an mp3 header and make it look like it's been ripped using a different method than the real one? And how'd you do that?

the reason for this is most likely because the files have been transcoded from a lower bitrate - or a different file format, which of course is always bad.

I'm pretty sure the files you have downloaded were transcodes. The net is full of shitty files. Try comparing the quality or take the samples length (you can see it in foobar's file properties window) and calculate:
samples mod 588

If you don't get a zero result, the file is a (mp3) transcode.

what's all the mod thing about? And how would I calculate that? I think you're refering to do the fact that transcoded mp3 files have 2 extra frames, right? Is there a plugin that does that nicely? I assume your calculations only work if the transcode has been made directly from a mp3 and not from mp3 based CD-Audio file...

To calculate it:
[ (_MOD_ the no. of samples) / 588 ] should equal zero.
e.g.
Nightbreed - Pack of Wolves (Pendulum Remix).mp3 --> _MOD_ of 7984452 / 588 = 0
base58 presents ULTRAMIX 91 PART 1.mp3 --> _MOD_ of 107029087 / 588 = 151 [foobar gives a '(rounded samples : 107028936)' for this file which does equal zero]

TBH I don't know what all this really means , but that's how to calculate it anyway.

Erm, I'm afraid you're messing some things up.

First, an explanation of mod:
"The mod operator returns the remainder obtained by dividing its operands. In other words, x mod y = x - (x div y) * y."
Oh, div is of course:
"The value of x div y is the value of x/y rounded in the direction of zero to the nearest integer."

Since 1 second on a CD is divided into 75 frames, each has 588 samples.
A mp3 is divided into frames and each has 1152 samples.

That's why we do "samples mod 588" to see if the source for the mp3 was a CD and not a transcode from a mp3.


Only the Special file info box gives this info. You get the "rounded samples" value if the file is not "(mod 588 = 0)". So those files are most likely transcodes (or post processed or not from a CD source).

I still don't get it...what do you guys use to make those mod calculations?

Hello

I have a similar question about the modification of LAME mp3 headers, which I think also belongs under this topic.
I'd like to change the nogap continued: and the nogap continuation: tags both from no to yes on some of my mp3's.
Is this possible?

Regards (and excuse my rudeness for imposing on your topic like this, thenormal. It's a great thing that you've started it. )

- Realityfreak

Ok, thanks for the explanation Gambit: some stuff I didn't know.
However, my calculations still work, I just don't think I explained it very well.


If you're on XP (or probably most Win OSs) get the calculator up: Start > Programs > Accessories > Calculator.
Then on the Calculator's menu bar: View > Scientific.
Then enter the number of samples, click 'MOD', enter 588, click 'equals', and you should get '0' (zero) if the source to your mp3 is from a CD.

That's right isn't it, Gambit?

Argh, you people... See? Your mommas told you that you will need that mathematics crap in real life one day...

You can calculate the mod with the Windows calculator in the Scientific mode.

But for those really slow individuals, here's an example:

A proper file encoded from a CD source.
Samples length: 10774512

10774512 mod 588 = 0

because:
10774512 / 588 = 18324
the result is a whole number, an integer.


Now, if the file was not created from a CD source:
Samples length: 10775855

10775855 mod 588 = 167

because:
10775855 / 588 = 18326,28401360544217687074829932
the result is not an integer, so:
18326 * 588 = 10775688
and:
10775855 - 10775688 = 167

Hope that makes it clear for everybody.

To simplify: mod is the residue of a division. If it is different than 0, the division was inexact. If it is equal to 0, the division was exact.

That makes no sense. And the nogap option is just an ugly hack that is not working properly and should not be used.

have you tried --alt-preset extreme -Y ? The -Y switch is an intelligent way to greatly reduce bitrates especially with metal and is not "stored", so applications like Mr Questionman or Encspot cannot tell you if it was used. If the bitrates match now, the mystery is solved...
Visually in a spectrogram view of the files, the -Y switch can mostly be guessed if there are only a few spikes which go above 16 kHz.

Thx Gambit. Probably rescued me from destroying my files!

- Realityfreak

oh well, I don't have any calculator program installed, but all you do is make sure that the number of frames foobar reports are part of 588 without any remainder...

I actually thought that you guys were using foobar to do this. Is there any good extension that checks for that? Maybe you could implement this in MQM as some sort basic of transcoding check. What do yout think?

The "Show file info (Special)" option in foobar2000 shows mod 588 for MP3 files. Though you must have this plugin installed of course

so where can I get that plugin? I guess it only works for one file at the time right...I still think it'd make a good addition to MQM though

It's in the Special installer.

is there a special installer available for beta 5, because I couldn't find it

Does this mod588 trick always work, or do I need a bit-perfect extraction (via EAC) from the CD? I mean if there are glitches during ripping, is there a chance that the outcome won't be mod588=0 altough it was ripped from CD?

No, this "trick" does not always work. I have many original rips that do not pass the mod 588 test.

Regards,
Madrigal

Please don't forget that only recent versions of LAME give sample accurate length. Old LAME (pre 3.90) and non-LAME mp3 encoders won't work.

does the file have to have a LAME-Header or at least a Xing Header (if VBR)?

A Lame Tag with the enc_delay and enc_padding values.

Every mp3 I have is LAME-encoded. The earliest version used was 3.90.3, the vast majority are 3.96.1, and I have only recently switched over to 3.97a10 and a11.

So this would not seem to be a factor.

I freely admit that I have some transcodes in my collection, but there are also many of my own rips, LAME-encoded as above, that simply do not pass the mod 588 test, based on sample lengths displayed by the Properties page in fb2k 0.9 beta 5.

EDIT: I have just read back through the thread, and the problem would seem to be that I routinely post-process my rips using GoldWave, to perform silence trimming before encoding. If I understand correctly, this is clobbering the original sample lengths, and therefore the subsequent mod 588 calculations.

Regards,
Madrigal

There you go...

Would it be possible to implement a guess of the source material using the described method into Mrquestionman? I for one would really appreciate such a feature.

that's exactly what I've mentioned. I'm not sure if Gambit likes it, because he hasn't made any comment on that so far. I think a good way of implementing this would be to check whether the file has a valid LAME-Tag and if so do the sample / 588 check.

Sure, sure. I use that check for a long time, I can put it in.

Thanks a lot!

It doesn't have to be just for a lame tag, it would work for any file with an accurate length.

I don't believe it! How many of those awesome features are you keeping back from us


not sure if that's a good idea. I mean, if you have foobar to add that info to let's say a FHG file doesn't necessarily make it transcode proof. But let's see how Gambit is gonna implement it. I can't wait for that feature

I've just noticed that files that were extracted from a CD as .wav for example and been modified to cut off silence parts or whatever, do not pass the mod 588 test, even though there are originals and no transcodes.

I noticed the very same thing, earlier in this thread. Note my conversation with Gambit about it.

Regards,
Madrigal

To sum up this part of the thread, then, it is not safe to conclude that a track is a transcode, simply because it does not pass the mod 588 test.

Regards,
Madrigal

another thing to note here is that transcodes from lossless files (as long as they were ripped directly from CD) will pass the test

I just noticed that transcodes with foobar will pass the mod 588 test as well. I transcoded from mp3 > wav > flac > mp3 and it didn't show up as a transcode. Even when I did mp3 > mp3 with foobar it passed it

Of course, because foobar's mp3 decoder decodes the files with sample accuracy, if the files have that info in the LameTag.