Reservoir Dogs (1992): Tarantino's 35mm Print Reconstruction

[pipefan413]

Oh my. Hey guys. Following the chat here, I'm going to look back at my original files and perhaps figure out what went wrong! Sorry for being AWOL.

I have a suspicion I know what happened to make the open matte so out of sync. I think I accidentally muxed the track synced to the main 35mm recreation project to that as well. With luck, I'll look through my original project files this weekend and see if I can find the properly synced version.

Regardless, I think that I ripped the Reservoir Dogs LD myself if I recall correctly but it was definitely not bit-perfect, so not sure what caused the glitch with the Side 2 audio.

PM'ed you, regardless pipefan413! Thanks to you and allldu for spotting these things!

As far as I remember, the only difference between the 35mm and open matte in terms of frames is the extra 48 at the start, but I've sorted that anyway; to a certain extent, RX has also corrected the discrepancy between the left and right channel levels although it would obviously be better to recap it with balanced levels than trying to fix it later as I've done here. I'll send you what I've got. And you're correct, that's precisely what it is: the audio for the 35mm version is muxed into the open matte one (I mentioned exactly that on MS).

If there are any differences between the two syncs apart from those initial 48 frames, I didn't have time to actually go through and check sync of the entire thing in detail before I went away on a quiet trip for a week, but every point I did check, they were in sync after adding 48 frames to the start of the 35mm (or removing them from the open matte) so I haven't resynced anything beyond that yet but at a quick glance sync looked fine as far as the film being watchable after the -2002ms correction. If it actually is different then by all means let me know but I'd need to rerun the RX adaptive level matching again on any "new" audio and I'm not at home (where RX is) again until next Friday so it might be easier if I send the fixed file and you trim samples corresponding to any frames missing from the DVD-based open matte version from the audio as appropriate. I'll send what I've got anyway, it's DTS-HD MA 2.0 Lt+Rt with the usual 1024-sample trim at the start to correct sync after encoding.

[pipefan413]

Right! So.

Home now and @allldu has pointed out that sync is now off by about 2 frames, which confused me (but didn't entirely surprise because I didn't have time to properly check everything in between packing to go on holiday for a week etc.) until I re-checked the original MKVs in eac3to and found that the audio on both of the audio tracks, and on both MKVs, was muxed in with a delay of -83ms.

What's slightly weird is that when I remux the MKVs to swap my new audio in, MKVToolNix automatically applies a -83ms delay... which I had already corrected for, meaning that the net result is that the audio ends up being an *extra* -83ms offset, putting it 83 ms ahead of the video stream.

So what I'm doing about this is as follows:

1. I've demuxed the audio again but this time specifically telling eac3to *not* to account for the delay; I then muxed that back into the same MKV to test and it was in sync, but this is because it has again been auto-offset by -83ms (which makes it the same sync as the original audio track with the wrong levels).

2. To see if I can get rid of this -83ms muxed-in delay entirely for a more tidy presentation, I've demuxed everything from the MKVs and am making completely fresh MKVs from the separate streams. I'm taking it that this -83ms is actually trying to adjust for a discrepancy of 2 video frames, so rather than adjust by -83ms this time I'm going to instead adjust by trimming the start as follows: 2 / (24000/1001) x 1000 = 83.417 ms, or more accurately, 2 / (24000/1001) x 48000 = 4004 samples.

3. As a wee bonus, I'm also adding the chapters from the Blu-ray, since the MKVs don't have any.

Have done the above and it's worked, so it's definitely something to do with the MKV container being hung up on this whole -83ms thing even when I replace the audio in it. That's good news though because it means I can fix it. So I'm also going to do the following tomorrow (it's nearly 3am):

4. Demux the .dtshd 5.1 track without accounting for the -83ms delay, decode it to .wavs, trim off precisely 4004 samples (negligible really but still more accurate than either the muxed-in -83ms or the closest possible .dtshd trim, which would be 512 / 48 x 8 = 85.333 ms), then encode back to a fresh .dtshd then correct sync with -21ms (I won't explain that all over again here but I've talked about it a lot on this forum already as well as elsewhere). This'll give a new .dtshd stream that doesn't need to be offset at all to precisely sync with the video stream.

5. Repeat the process with the Open Matte version of the project (which I suspect is likely to be my preferred version, actually). I've already fixed the audio sync but I would prefer cleaner MKV files. To do that, all the audio and the chapters will be offset by 48 (video, not audio) frames, which I already did previously anyway so that's very easy to repeat.

One thing I'm going to do as I go through this is make sure that my new .dtshd files decode back cleanly to PCM without any decoding issues right at the beginning. Again, like the -21ms thing, I won't bang on about this here but the gist is that you need to have a bit of 100% pure silence at the beginning for .dtshd or indeed lossy DTS to decode properly, otherwise you get teensy binary-level issues that may be a total non-issue or may manifest as an actual audible pop in the waveform. I think these are fine but they are not cleanly decoded at the first frame or two because there's no clean silence at the start, so I'm going to create some by stripping a small bit of what appears to be dither noise from the start of the bitstream. This'll mean that you get a nice tidy .dtshd stream that will decode back to the exact same PCM that it was created from.

Anyway, will report back once all this is done and I've got shiny new MKV files. I'll probably share the new audio files and possibly chapters separately in case people don't want to download whole new files but it's very important you completely demux any existing MKVs and remux the video stream to the new audio stream from scratch, otherwise it'll all by 83 ms out of sync.

[pipefan413]

Right, so here goes.


DEMUXING

Video and subtitles:

Code:

eac3to v3.34
command line: eac3to  Reservoir_Dogs.mkv 1: RD35.* 4: RD35.srt
------------------------------------------------------------------------------
MKV, 1 video track, 2 audio tracks, 1 subtitle track, 1:39:10, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: RAW/PCM, English, 2.0 channels, 16 bits, 48kHz, -83ms
  "Original Stereo"
3: DTS Master Audio, English, 5.1 channels, 16 bits, 48kHz, -83ms
  (core: DTS, 5.1 channels, 1509kbps, 48kHz)
  "5.1 Surround Remix"
4: Subtitle (SRT), English
[v01] Extracting video track number 1...
[v01] Creating file "RD35.h264"...
[s04] Extracting subtitle track number 4...
[s04] Creating file "RD35.srt"...
Video track 1 contains 142657 frames.
eac3to processing took 11 minutes, 46 seconds.
Done.

Dolby Stereo mix:

Code:

eac3to v3.34
command line: eac3to  Reservoir_Dogs.mkv 2: RD35+83ms.wav +83ms
------------------------------------------------------------------------------
MKV, 1 video track, 2 audio tracks, 1 subtitle track, 1:39:10, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: RAW/PCM, English, 2.0 channels, 16 bits, 48kHz, -83ms
  "Original Stereo"
3: DTS Master Audio, English, 5.1 channels, 16 bits, 48kHz, -83ms
  (core: DTS, 5.1 channels, 1509kbps, 48kHz)
  "5.1 Surround Remix"
4: Subtitle (SRT), English
[a02] Extracting audio track number 2...
[a02] Reading RAW/PCM...
[a02] Writing WAV...
[a02] Creating file "RD35+83ms.wav"...
[a02] The original audio track has a constant bit depth of 16 bits.
Video track 1 contains 142657 frames.
eac3to processing took 3 minutes, 11 seconds.
Done.

N.B. There is no "apply RAW/PCM delay" because although eac3to knows that it's muxed with -83ms, I've explicitly told it to ignore that with "+83ms", so it isn't applying the delay as it did previously (I'm going to apply it manually by stripping 4004 samples instead).

Chapters:

Code:

eac3to v3.34
command line: eac3to  RESERVOIR_DOGS 1) 1: RDchapters.txt
------------------------------------------------------------------------------
M2TS, 1 video track, 3 audio tracks, 2 subtitle tracks, 1:39:08, 24p /1.001
1: Chapters, 28 chapters
2: MPEG2, 1080p24 /1.001 (16:9)
3: DTS Hi-Res, English, 6.1 channels, 3039kbps, 48kHz
   (core: DTS-ES, 6.1 channels, 1509kbps, 48kHz, dialnorm: -4dB)
4: AC3 EX, English, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB
5: AC3, English, 2.0 channels, 640kbps, 48kHz, dialnorm: -27dB
6: Subtitle (PGS), English
7: Subtitle (PGS), English
Creating file "RDchapters.txt"...
Done.

LASERDISC AUDIO REPAIR

1. Replaced first 101138 samples with pure silence followed by a short crossfade, both to remove an audible pop at the start of the audio and to clean it up (mostly for .dtshd encoding then decoding purposes but also because it was quite unpleasant hearing some low level noise, then a big pop, then magnetic hiss, then what sounds like monitor hum, all before the actual recorded film audio starts with background café chatter). I can provide a comparison if anybody cares to hear the difference here.

2. Removed first 4004 samples in RX (more precise version of -83ms muxed delay in source MKV)

3. Dynamically adjusted level and alignment of right channel to better match left channel (since right channel was significantly quieter than left channel previously and didn't align all that well either)

4. Added a fade out at the end so it doesn't fade the music out to a big stinkin' background hum then abruptly stop.

5. Checked the length of the audio against the video and adjusted it with DTS in mind. The video contains 142657 frames and 142657 / (24000/1001) x 48000 = ‭285,599,314‬ audio samples but the audio file contained 285,595,310 samples; 285,599,314 - 285,595,310 = 4004 samples... which is probably not coincidentally the exact number I removed from the start. Hmm. Nonetheless, converting this for DTS purposes makes it 285,599,314 / 512 = 557,811.160, rounded down is 557,811 * 512 = 285,599,232‬ to the nearest whole DTS frame. Note that any number between 285,598,721‬ and 285,599,231‬ will end up being rounded up to 285,599,232‬ during .dtshd encoding anyway but I may as well add the right number to begin with so I added 285,599,232 - 285,595,310 = 3922‬ samples of silence to the end (slightly less than the original 4004 so that it won't round up and extend beyond the end of the video stream.

6. Saved as a 32-bit float so I could come back to this later if needed.

7. Dithered the whole lot back down to 16-bit with a flat TPDF. Usually I'd use auto-blanking such that it only dithers stuff that isn't quantised, but since this would result in only the right channel being dithered for the vast majority of the runtime in this case and that bothered my happiness, I switched auto-blanking to only ignore silence and dither everything else uniformly.

8. Saved to rd35c.flac for archival and further processing.

9. Removed another 96096 samples of 16-bit silence (truncated from 32-bit rather than dithered, since it's pure silence and doesn't need dithering) from the start for the open matte version, saving that as rdomc.flac. It's 96096 samples because 48 frames of video at 23.976 fps is equivalent to 48 / (24000/1001) x 48000 = 96096 PCM audio samples, so that's what I trimmed here (same as I did when I did my slapdash fix before I went on my COVID-restricted holiday).

10. Split rd35c.flac to two .wav files, one for each channel...

Code:

eac3to rd35c.flac rd35c.wavs

11. Encoded to rd35c.enc.dtshd with L -> Lt and R -> Rt (so that it decodes back to surround, as Dolby Stereo should) and a 639 kbps core to keep file size down without noticeably downgrading quality even if you can't decode the track losslessly (you can always decode to PCM if you prefer anyway).

12. Trimmed extraneous .dtshd crap to reduce bloat and correct sync by 1024 samples at the start:

Code:

eac3to rd35c.enc.dtshd rd35c.dtshd -21ms

13. Repeated steps 10 to 12 for rdomc.flac.

Result of the above is two .dtshd streams with 639 kbps DTS cores: rd35c.dtshd for "Tarantino's 35 mm Print Reconstruction" and rdomc.dtshd for "Open Matte Sundance Premiere Reconstruction".


ALTERNATIVE AUDIO

I briefly checked out the 5.1 and for the time being have decided not to bother with it. Apart from it being a remix (which is fundamentally revisionism regardless of whether it's good or not), and the fact it's demuxed from TrueHD (which is notoriously iffy in general compared to DTS-HD so I don't trust it), there are some other things that make it less interesting to me. For a start, the beginning hasn't been sufficiently trimmed so it has some leftover audio from what I assume is a distributor logo (which would be easy to remove, but still). Secondly, my Blu-rays - UK ones - both have a 6.1 track instead, which I'm guessing more accurately represents the remix master as it was intended to be heard when created (there's also a lossy core which is 5.1 but even that has a matrixed additional surround to get faux-6.1). It would appear that my original copy has this as DTS-HD HR with a DTS-ES core, and the newer copy from the XX box set seems to have it as DTS-HD MA instead. I'll probably have a look at these later but for now I'm just focusing on getting the 2.0 Dolby Stereo mix as listenable as I can manage without a massive amount of manual work.


REMUXING

Easy: chucked it in MKVToolNix, no delays because everything's synced up nicely now.

For the open matte, I had to adjust the chapters by removing 48 frames' worth of time from every chapter timestamp, which is 48 / (24000/1001) = 2.002 seconds. I also ported the subtitle track across from the other MKV with a -2002ms delay.

EDIT: And uh... after all that, I think I'm also going to just recapture it off LD myself, since I've just grabbed a player and it's relatively cheap anyway. I need to stop spending money though, I'm absolutely rooked now... But for the meantime anyway, this is significantly better than it was to begin with and at least the audio for both versions is now in sync!

EDIT (because I realised I hadn't said this): This is all done now by the way, it's currently uploading in case my hard drive craps out or something. There was something wrong with the original MKV files causing the whole -83ms thing so it's probably best that you either just use the files I've made myself or demux and remux completely (with just the new audio, and maybe I can give you the chapters as text if you like) rather than remuxing the MKV to another MKV directly.

Also... yeah, I bought the damn LaserDisc. Hoo boy.

[pipefan413]

I've now captured both the pan & scan (LD68993) and letterboxed (LD68993WS) US LaserDiscs, with analogue and digital audio. The analogue track appears to be in sync with the video throughout (phew) so the current idea is just to take that as the target, align the digital audio, and then sync the video tracks in AviSynth in order to identify the areas where there are frames missing from either the source LaserDiscs or target video. Incidentally, the "target video" here is two different ones: firstly the French 1.33:1 DVD (and by proxy, TAF's "open matte" project), and secondly the Japanese Blu-ray (and by proxy, TAF's "Tarantino's 35 mm print" project).

These digital captures are "bit perfect" within reason (by which I mean verified accurate apart from tiny variations at side change and end) but I want to take a bit of time to make absolutely sure they're the most accurate possible representation of what's on the discs before I start resyncing them, meaning I'll combine all the rips into one Frankenstein Ubercap that has every possible byte I can squeeze out of my player and capture hardware. I did something similar previously for NEAR DARK as well (which I haven't tried to sync yet either, because I've been focusing on making sure my capture workflow is sensible and does what I need it to do).

I'm also having quite significant and incredibly frustrating issues with IVTCing this film because the automated filters I've tried (TIVTC and Decomb) both seem to screw up starting right around the slow mo opening titles where Little Green Bag plays over the characters walking down the street. It should be displaying each frame three times before moving to the next frame in the sequence, which is what the French DVD does (that's PAL of course so doesn't have the complication of needing IVTC). What it does instead is display some frames once, some twice, some 3 times, some 4 times, and so on (in other words it must be discarding frames as "duplicates" that are duplicated intentionally and should stay in the film because they were actually scanned off the print). As a result, the film is out of sync with the PAL DVD by a fair few frames by the end of the opening titles, and it loses more further into the film. I could perhaps just assume that the sync is the same for them both up until after the end of the title sequence and hope that works out OK, then IVTC the rest and see how it goes, but then I'd be worried about further discrepancies and it just kinda feels like a big ol' headache. I haven't really decided how to handle it, but I guess I could just forget the whole IVTC video sync idea for this one and sync the waveforms in something like REAPER or even just Audacity. I dunno.

But yeah, anyway, about that whole weird issue with the balance being wrong (as noticed and raised by @allldu) and suddenly getting much worse around the Stealers Wheel scene? It ain't TAF's fault in any way: the audio is like that on the widescreen LaserDisc. So yeah the capture was resampled to 48 kHz, but that's honestly pretty much a non-issue as long as the resampling is reasonably transparent, but the much bigger issue is the balance being screwed up between L and R and that's unfortunately endemic to the source.

HOWEVER... the issue is NOT present on the pan & scan LaserDisc! So I guess that's our new main source. I'm going to keep the widescreen capture for now but it's probably not very useful. Here are my captures of the widescreen LD and the pan & scan LD at the exact moment it most noticeably goes way out of balance. Notice that the right channel on the widescreen cap (bottom waveform) drops significantly around 55:42 mark, but the pan & scan track remains balanced.



So yeah, I'll sync this at 44.1 kHz and export as 16-bit FLAC, then resample it to 48 kHz and encode a DTS-HD Master Audio version as well (Lt+Rt with the 1024 samples silence knocked out and verified for bit perfect decode, as usual for me).

[The Aluminum Falcon]

Wow! Thanks for the detective work, pipefan. Looks like your purchase of the Pan & Scan laserdisc paid off

Happy to have the audio finally available in bit-perfect.

[pipefan413]

Wow! Thanks for the detective work, pipefan. Looks like your purchase of the Pan & Scan laserdisc paid off

Happy to have the audio finally available in bit-perfect.

I have at least found a use for my bit perfect capture of the widescreen LaserDisc: *before* the levels go absolutely nuts, it has a huge patch that I need to fill a very large gap on the pan & scan LD (39 frames! holy crap!) so I'm most likely lifting a big chunk from around the 47 minute mark and plonking it into the P&S cap as carefully as possible to make sure it's seamless. On the P&S it just cuts to halfway through Mr Pink shouting "--uck you!" so it's really noticeable!

[pipefan413]

Right! So, the "open matte" capture and resync is done for the French DVD. The most significant edit was a pretty big patch of audio pertaining to 39 frames missing after a cut somewhere around the 47-minute mark on the pan & scan LaserDisc, which luckily were absolutely fine on the widescreen LaserDisc, so I lifted it from there and patched it in (not necessarily exactly 39 frames' worth but rather the most seamless edit point that would both insert the missing audio and not create any kind of audible transition). Apart from that, it was all purely realignments: deleting the side change accurately, applying extensions and crossfades to pad the audio by 1 or 2 frames' worth at a handful of other scene transitions where there were some other frames missing. The resulting audio lines up pretty well with the audio from the French 1.33:1 DVD after PAL 25 fps -> 24000/1001 fps time correction, though not 100% precisely because I was more interested in doing the least destructive resync than getting a 100% match to audio that was ostensibly a 5.1 remix anyway.

I initially was going to leave it there until I checked some scenes and was pretty sure that the sync from the LD source was too early, meaning that sounds were being heard too early compared to what I was seeing on screen, so then I completely overhauled the whole thing to abandon the idea of resyncing based on the video and instead just resynced it mostly to target the French DVD audio (which I no longer think is actually a remix but potentially just a 5.1 version of the original theatrical mix, since it actually syncs up really *really* closely for big chunks of runtime after some adjustment to offsets and the like). I say "mostly" because I found some moments where the French DVD sync was also not quite right, with things like punches sometimes being heard either way too early or way too late, so I opted for a compromise between slavishly following the French DVD audio and "fixing" areas where it wasn't quite right by realigning it in AviSynth by watching the audio waveform alignment to video frames in VirtualDub (which I didn't even know you could do until I found that feature *after* I'd done the first version of the resync). This was extremely handy because it meant I could look at stuff like punches and car crashes in both the target video and the resync/source audio, to make sure that those big waveform spikes were not landing any earlier than the frames on which the punch landed and so on (generally, audio being slightly too late is basically a non-issue, but it being too early is a huge problem because you would never hear something before you see the thing making the sound since light travels way faster than sound, so it makes your brain do somersaults).

Anyway, next move is resyncing to Blu-ray / @The Aluminum Falcon's "35 mm" regrade (which looks all kinds of amazing to me) since that too had audio sourced from the problematic widescreen LaserDisc. I'll basically be taking the hybrid master I made for this DVD resync and reworking it to fit the Blu-ray instead, since I've already done a big chunk of the work and I imagine they'll probably match up reasonably well although they'll obviously be from different sources. I'm annoyed the widescreen LaserDisc audio is mostly crap but it was a godsend being able to sample that big chunk of missing sound that was missing from the 4:3 LaserDisc main source!

[captainsolo]

So I guess I shouldn't have bought the widescreen LD as my version to have on hand...LOL

[pipefan413]

So I guess I shouldn't have bought the widescreen LD as my version to have on hand...LOL

Well, it was still a life-saver here as a patch source because they're obviously from different prints! But aye, not ideal that the level balance is borked. It did help running it through RX but then you wonder if it's levelling things out that aren't supposed to be level (effects that should remain stereo-ised, with something only happening in the left or right channel or just being slightly more panned to one side or the other). So I reckon the fullscreen is the better resource.

[freedomland]

@pipefan413
I am looking everywhere to see what differences could make a look into Laserdisc-releases of Reservoir Dogs. Since I have no Player nor the discs yet, you might be able to tell me or show me the differences? I signed in today, so it seemed I cannot pm you right now for this issue.