scene release theory

[Talim_]

As I'm sure most people on this forum know by now it's trivial to use rescene with srr files from srrdb to recreate original scene releases from retagged files. Before Google Play Music was shut down I had some fun with this idea by downloading songs from the service myself and using the srr to create the releases. By doing that it was possible to have an in tact scene release with mp3 files that never touched a scene site. It's very possible that in searching p2p networks you will come across shared files purchased from popular sites of the past like Beatport and be able to reconstruct a long lost release with them.

Now here's a crazier idea. What if we can replicate the conditions of original CD rips from the past to recreate the encodes? As a simple test I took a wav and encoded it twice with Lame 3.90.3 modified to be period accurate. Both times it achieved an identical result. I think the biggest problem with this insane idea is trying to replicate the exact setup the rippers used. Typically your group leader would distribute you the tools they used. They weren't always the latest versions of EAC and Lame. Tracking the versions of Lame used and the settings are easy but EAC will be much trickier. Perhaps just the default with burst mode would be enough? But those kinds of settings could introduce artifacts which would make this much more difficult. Just an idea lol

[aGGyunit]

I had a go at this a few months ago, even with the exact encoding settings and using the lame version specified in the nfo I was unable to reproduce (from .wav) the exact rip they made.

I think your theory would need some testing. Does an encoder behave the same on 2 different PCs.
For example, if we both use the same source file and encoded it with Lame v3.100 on 2 different PCs (1 Intel and 1 AMD), does it produce the same file with the same CRC.
How about windows 10 vs Ubuntu / Linux Mint ... does it produce the exact same file?
How about VBR? If I encoded a WAV to VBR 3-4-5 times, are the created files always identical?

Like you said, how much does the source file matter in all this?
Did they use EAC back then, what version and settings? Or did they use AudioGrabber / AudioCatalyst back in the day ...
Could even be different between brands of CD/DVD drives...

So many variables ... interesting theory tho.
Gimme a shout if you want to compare some encoded files or trial something.


With your Deezer files to recreate the scene release ... that just proves that a lot of groups are using the easy way out and using Deezer files and LIE about it.

[DaScientific]

To this point im pretty sure, that this method will not "recreate" the original Scene files. Did you try to match the files you created with the original SFV file?
So in the case you are not missing a whole release but missing some files of a release, im pretty sure that this method will not create "bit-exact" files. Am I wrong on this?
My personal point of view is: your are creating P2P-like IND-releases, but falsely tag them (just my personal 2 cents).

[Talim_]

To this point im pretty sure, that this method will not "recreate" the original Scene files. Did you try to match the files you created with the original SFV file?
So in the case you are not missing a whole release but missing some files of a release, im pretty sure that this method will not create "bit-exact" files. Am I wrong on this?
My personal point of view is: your are creating P2P-like IND-releases, but falsely tag them (just my personal 2 cents).

The point is to make bit exact files. Anything less would be unacceptable. In theory it should be possible, in practice it would be a difficult feat to pull off. When I find time I am going to try some of aGGyunit's suggestions to rule things out. In some tests I did I noticed that even though I'm using the same Lame version the padding put in the file by the encoder was sometimes different. I think not just the OS but however the version of Lame was compiled might be important. The best possible time period of releases to pull this off with would likely be the ones from 2004+ when they first adopted VBR and everyone was using the modified Lame 3.90.3 from dibrom. It's very easy to assume most groups in that time period were using the same lame.exe.

[Talim_]

After testing encoding with my AMD laptop and my old Intel one with the same settings on both I can confirm the files are identical. Same thing when encoding to flac then decoding the flac back to wav. I remembered that on torrent sites like what.cd and redacted their guides tell you to check a setting in EAC called "Fill up missing offset samples with silence". Maybe a lot of the flacs findable around the internet aren't good candidates for this because of that. Maybe burning them to a CD-R using the included cue sheets then ripping with the option unchecked would help. If not having the original CD and it being the same pressing would be necessary. I can recall groups I joined back then telling me to rip with EAC in secure mode. There wasn't really any kind of enforcement on that though. It's not like they asked for the log file or anything, checking rips back then mostly involved looking at the encoder used and later on the settings.

[aGGyunit]

Interesting.

Where do we go from here? Anything else you want to try?

Or can we safely say that we need the exact source file to replicate old MP3s?

[avarage]

you can find out lame version with mediainfo or encspot.

but i don't think you are able to recreate original wav files from mp3 files.

[Talim_]

Code: Select all

OK. 

I can't stand it anymore. Seeing rippers good releases get nuked because of this encode misunderstanding
is is too much for me to bare. For everyone who doesn't know it yet there can be a bug with EAC and Lame 3.90.3
if you set the external encoder to :Lame Encoder" instead of "User Defined".

Well, just kill the prob on the spot and check out below.

1. Start using Lame 3.97 TODAY! (if you aren't already)
Get it here - http://www.rarewares.org/dancer/dancer.php?f=109

2. Get the newest EAC (if you don't have it yet)
German Page - http://www.digital-world.de/index.cfm?pid=303&pk=1253374
English Page - http://www.digital-world.de/downloads/audio/software/1253089/index.html

3. Go to your Compressions tab in EAC - F11 \ External Compression
Check "Use External Compression"
Parameter Passing Scheme = "User Defined Encoder" >>>> NOT Lame MP3 Encoder!
Browse to your Lame.exe (3.97!) if you didn't just replace your old one.
!ATTENTION! Additional Command Line Options = -V2 --vbr-new %s %d 
The other check boxes are optional (even though I think it will auto set Bit Rate to 96kBit/s

4. Download Audio Identifier - http://www.bitattack.com/ or http://www.bitattack.com/catalog.html#AI
Browse to the mp3s you want to check. 
Right Click and choose "Display Lame Tag"
The important lines to check are: 

Version string:  3.97 

Quality: 77 (V2 and q3) (Attention, if its V1 or V0 expect the nuke!)

Encoding method: vbr old / vbr rh (or mtrh)

ATH type:  4

Noise shaping: 1  (Attention, if its value is 2 or higher expect the nuke!)

V2: preset standard or V2: preset standard (fast mode) 
- the suggested command line parameter in the Council Nfo  ("-V2 --vbr-new") will 
give V2: preset standard (fast mode) -

- This is what I have heard are the important results to watch for. I have no idea technically why they 
are important (soundshape?) but of course it gives us the quality level of the encode. If you want to know more
You will have to search that out yourself. I'm just passing on what I was told were the problems with the nukes
as of late. 
SO: I'm putting this info out to stimulate everyone and hopefully clear up confusion. If there is anything incorrect
with this info I'm also hoping it will create an impulse to correct it, so that by next week EVERYONE
knows what the hell is going on and how to fix it for themselves!

____________________________________________________________________________________________________

Some ppl will have a smartass answer and say it was in the nfo blah blah, but I don't know why
these encoding parameters weren't stated more clearly. (No i'm not talking about "use lame 3.97 with 
-V2 --vbr-new") but the exact parameters for EAC and the fact that there was a bug. I for one didn't know
about this and thought I had been sticking "to the rules". 
Also I don't know why there wasn't more of a deal made (A count down - "7 more days and scene rules will
be in effect so be ready everyone". (Again for the smartasses: Yes the dates are in the council rules
but the real world is different plus the fact again that some ppl thought they WERE encoding correctly and HAD
read the info using the CORRECT presets. Why would this all be happeing if it was "so clear"?
But as we know some ppls egos are boosted by others mistakes so i'm sure there is even an enjoyment by some 
that THEY knew it already instead of us all just getting together and helping each other out when we saw 
there was a confusion).
It would have saved everyone so much time and effort if this stuff had been more accented. But yes, it was 
in the info right? Well, If THIS info i'm posting now had been passed around IN the council rules or at least
spread in the beginning of January it would have saved alot of rippers works and Nukenet nukes. But from what
I have heard nukenet doesn't mind that anyway do they? Now they can show their stuff. 
I mean this whole deal was started and signed by 50+ groups so it was in everyones interest to have the whole 
lowdown. Or am I wrong?

Anyway, I hope this updates all good rippers (and racers) to what is going on when you see a nuke and it only says
"Read Rules" (Jezuz that tees me off).

Power to all the blokes that keep this great mp3 scene going and hopefully in a couple days we won't see anymore
"Read Rules" nukes, at least for encoding. Tagging is another subject for another info :P

PZ

Found this nfo in one of the packs for a group I was in, I'm sure it's probably on that scene notice site too but it's perhaps useful info

The Lame 3.97 pack from rarewares is in the internet archive, this is the link that url leads to: [External Link Removed for Guests]

[omarijamarija]

Very interesting idea. I had the same thought lately, about recreating scene files by ripping CDs and encoding files using old encoders with exact same settings. However, I quickly gave up on it. Just as it was already mentioned, there are too many variables to take care of. Not to mention finding binaries used back then is already a tough task itself. Then you have to run it with the same exact parameters and hope you're in the possession of the same pressing. In worst case scenario, what if original ripper's copy had some specific error that hasn't been corrected. You can virtually recreate all the conditions, but that one is extra hard one!
Not worth trying imho, but good luck to you!

[Talim_]

I have finally had a success. [External Link Removed for Guests] Using the 32 bit version of Lame 3.100 from here I recreated Toni_Braxton-Spell_My_Name-2020-C4 from Toni_Braxton-Spell_My_Name-CD-FLAC-2020-PERFECT. I decoded the flac files to wav with the latest version of the flac.exe then encoded to v0 with this lame exe and it worked fine. It does not work with the 64 bit exe.