Welcome, Guest |
You have to register before you can post on our site.
|
Forum Statistics |
» Members: 5,233
» Latest member: baqzxzxz
» Forum threads: 5,806
» Forum posts: 84,900
Full Statistics
|
Latest Threads |
Hello!
Forum: Presentation
Last Post: Mut2000
Today, 12:38 AM
» Replies: 0
» Views: 23
|
TROY (2004) - Replace Sco...
Forum: Requests, proposals, help
Last Post: NL197
Yesterday, 10:53 PM
» Replies: 10
» Views: 6,344
|
"Heat" theatrical cut reg...
Forum: Released
Last Post: Johnsmith17230
Yesterday, 06:59 PM
» Replies: 3
» Views: 149
|
Hi there
Forum: Presentation
Last Post: jacob56rob
Yesterday, 02:12 PM
» Replies: 0
» Views: 29
|
Greetings and salutations...
Forum: Presentation
Last Post: RadioSignal
Yesterday, 02:00 AM
» Replies: 0
» Views: 38
|
Hello, my name is Zero.
Forum: Presentation
Last Post: T-Zero
Yesterday, 12:35 AM
» Replies: 0
» Views: 35
|
Running Man 35mm open mat...
Forum: Requests, proposals, help
Last Post: Moonlight Mystrio
2025-07-04, 04:53 PM
» Replies: 53
» Views: 33,261
|
Rambo trilogy original mi...
Forum: Requests, proposals, help
Last Post: uVSthem
2025-07-04, 12:06 PM
» Replies: 82
» Views: 62,960
|
Lethal Weapon UHD resyncs
Forum: Requests, proposals, help
Last Post: weegee2392
2025-07-03, 06:22 PM
» Replies: 21
» Views: 1,964
|
The Dollars Trilogy 4K UH...
Forum: Official and unofficial releases
Last Post: marin888
2025-07-02, 12:26 AM
» Replies: 15
» Views: 2,589
|
|
|
Highlander II - 35mm Grindhouse Edition |
Posted by: HippieDalek - 2020-05-29, 08:32 PM - Forum: Released
- Replies (59)
|
 |
After months of discussion in this thread I'm finally able to release the entirely unrestored scan of a Russian Theatrical 35mm print of Highlander II: The Quickening!
This is the 100 minute European/International cut of the film, which is very different from both the US Theatrical Cut and the later Renegade Version, and features none of the CGI additions of the Special Edition.
The MKV contains chapter points at the start of each reel, and both English stereo (from the Hong Kong laserdisc) and Russian mono (from the print) audio. Both are unrestored, so expect even the English laserdisc audio to sound a bit rougher than the restored English track I used on my Standard Definition preservation.
![[Image: DACMB6l.jpg]](https://i.imgur.com/DACMB6l.jpg)
Time to set some expectations though. As you'll know if you followed the scanning thread, reel 1 of this print is what I would describe as "splicey". There was a lot of damage to the first reel resulting in many splices and jumps in the footage. I've synced the laserdisc audio to the spliced footage but it can make for a sometimes difficult viewing experience. However things significantly pick up once reel 2 starts (around 19 mins, when MacLeod goes to the bar). The other reels fair a lot better but there are still some (but far fewer) splices during the rest of the film, along with the usual scratches, dirt and occasional discolouration.
So this grindhouse presentation may be a little more "grindy" than others.
Despite the damage the colours and detail remain excellent throughout. In most comparisons I've made so far the detail of the print usually outdoes the detail available on the Blu Ray, and of course this offers the original theatrical colours.
I plan to use this scan, combined with the Blu Ray and other sources, to attempt to re-create the film in full HD. However as you'll see from this scan there is a long way to go.
For now I hope you enjoy, and please let me know if you have any feedback 
Thank you to everyone who made this project possible! This would not have happened without you.
PM me for links.
|
|
|
DTS-HD Master Audio and bitrate (PBR) smoothing |
Posted by: pipefan413 - 2020-05-29, 04:58 PM - Forum: Converting, encoding, authoring
- Replies (4)
|
 |
OK so this is bloody complicated and my brain is soup but I'll try my best to lay this out as clearly as I can. I know this is an extremely long-winded post, so feel free to completely ignore me or maybe just skim it and then read the bits in more detail that you think you might be able to clarify. It might be that this is entirely the wrong forum to ask this kind of specific question, but I figure it's worth a bash before I go poking about Doom9 or wherever else. Anyway, here goes...
1: What the hell is bitrate smoothing?
I was in the process of redoing my Snowpiercer resync to make it more accurate than it already was, which involved me decoding the .dtshd 7.1 audio track off a Blu-ray Disc to PCM, inserting some samples of silence for precise sync, then re-encoding it back to .dtshd again. The thing is, when I encoded back to DTS-HD MA, something weird happened: the new file was significantly smaller, despite being encoded losslessly in the same format as source. After testing my whole workflow for any losses and verifying that there has been no audio data lost at any point in the chain, I think I've possibly worked out why, though...
The DTS-HD Master Audio Suite encoder produces 2 files:
- a .dtshd audio bitstream file, which has variable bitrate
- a .dtspbr file, which contains an analysis of the changes in bitrate throughout the .dtshd audio bitstream
When you author a disc, pro authoring software uses the PBR (Peak BitRate) analysis contained in the .dtspbr file to "smooth" the bitrate so that it's more consistent across the whole bitstream, or as the DTS encoder's manual puts it...
Quote:The Peak Bit Rate Analysis Tool analyses variable bit rate encodings (DTS-HD Master Audio encoded streams) graphically plotting the selected encoding’s bit rate over time, as if the encoding had been “smoothed” for authoring using a Peak Bit Rate scheduling utility. The smoothing process redistributes data throughout the encoded stream for a more constant flow of data during disc played back. Smoothing is performed during the authoring process of a disc.
I think the point of this is to work out where in the bitstream the bitrate suddenly jumps from low to high or high to low, and smooth (i.e. make more gradual) that transition so it's less abrupt. I'm not sure why this is necessary but I assume it's to stop some part of the hardware/decoding chain freaking out because of sudden bitrate spikes (I'd guess that decoders might deal with this badly and fail to increase the bitrate sufficiently fast enough to output losslessly, which could potentially result in audible degradation of the output). Now, if the PBR smoothing is doing that, you'll presumably end up with more areas of higher bitrates, since it's presumably slowly increasing bitrates over a longer time period rather than letting it stay low and then suddenly spike where needed; it follows that these areas of padded-up bitrate will make the file bigger. This might explain why the .dtshd file demuxed off a retail Blu-ray Disc was roughly 10% larger than my .dtshd encode fresh out of the DTS Suite, since mine had not yet gone through the bitrate-smoothing process (since this is only done when you actually author it to disc).
Now, to actually author a .dtshd stream to disc in a way that puts it through this bitrate-smoothing process, you need to take something else into account...
2: The DTS Suite header
If you author a .dtshd stream to disc using something like tsMuxeR, it'll just ignore the whole bitrate-smoothing thing altogether as far as I can tell, since it doesn't prompt for a .dtspbr input or give any indication that the output file is not going to be disc compliant. However, if you try to do it in pro authoring software like Scenarist, it will prompt for the PBR analysis to be included so that it can smooth the bitrate out in the audio stream it puts on the disc. In order for this process to work, you need to have two things:
- a .dtshd audio stream with a DTS-HD Master Audio Suite header attached (which goes before the actual DTS header and the audio bitstream itself)
- a .dtspbr file containing the PBR analysis
You can use a component of the DTS Suite called StreamTools to generate a PBR analysis if you don't have a .dtspbr file, but in order to do so, your .dtshd file needs to have this extra DTS Suite header. The trouble is, .dtshd streams demuxed from disc do not contain this header because it's stripped off during the authoring process, so you can't simply demux .dtshd from disc then plug it into StreamTools to generate a .dtspbr that you can then use to author back to disc later. I'd guess this is probably by design as an anti-piracy measure, which makes sense. (Note: I have no interest in circumventing this for the purposes of piracy; I'm only interested in correcting mis-steps made by official releases that I have bought multiple copies of, so that I can combine the best elements of each.) Furthermore, if I'm correct, it seems that .dtshd streams taken straight off a disc already have their bitrates smoothed out, so even if you did somehow manage to attach a new DTS Suite header and generate a PBR file, it would be analysing an already smoothed bitstream rather than the sort of un-smoothed variable bitrate stream that the encoder would have produced in the first place.
So, assuming that you wanted to author a compliant Blu-ray Disc using both a .dtshd stream and a .dtspbr file, you could do what I've done thus far: get the .dtshd stream off the disc, decode it to PCM, then feed it back through the official encoder in order to generate a new (non-smoothed, smaller) .dtshd audio stream and an accompanying .dtspbr bitrate analysis file to later feed to your authoring software. Right?
Well.. no, not necessarily, because there's something else that the encoder does to its output.
3: The sound of silence
Turns out that when you encode to .dtshd in the Suite, it adds something else to the start of the file in addition to the aforementioned extra header: 1024 audio samples' worth of zero byte silence. In terms of duration, this is equivalent to a little over 21 milliseconds (1024 samples / 48000 sample rate = 0.021333... seconds). So you can see what I'm talking about visually, here's a mono audio track that's been encoded to .dtshd then decoded back to PCM, both before and after I removed the added 1024 samples of silence at the start. I've highlighted the 2048 zero bytes (silence). The bit depth for this audio file is 16-bit, meaning that one audio sample consists of 16 bits, and there are 8 bits in a byte, so 16 bits / 8 = 2 bytes per audio sample. 2048 / 2 = 1024 samples.
Now, this is an easy thing to fix if you're muxing to MKV, because you can simply apply a negative delay in eac3to like so:
Code: eac3to inputfile.dtshd outputfile.dtshd -21ms
Note that this might seem at first glance like it isn't completely accurate because 1024 samples is not exactly 21 ms, but in practice, eac3to rounds the 21 ms up so that it does happen to cut off precisely the 1024 samples we want to remove.
Anyway, if you're looking to actually author it back to a disc (and potentially put it through the bitrate smoothing process discussed above), well...
- It may not necessarily be as simple as deleting the 1024 samples and either reusing the existing .dtspbr file or generating another, since I'm not certain whether the header will still be correct for the contents of the file after removing 1024 samples from the start of the bitstream.
- It might not even be correct to remove the 1024 samples of silence if authoring a disc anyway, which brings me to my final point...
4: I sync my mind is melting
The thing is, there surely has to be some reason that the DTS Suite encoder is inserting 1024 samples of silence in the start of the bitstream in the first place. Until recently, I had absolutely no idea why that might be, and I might still be miles off on this but I may have stumbled upon a very fuzzy semblance of understanding while working on something unrelated.
I was working with a graphical (as in, images, no text) PGS subtitle stream for another film and during testing, I muxed one of my PGS streams into the appropriate AVC video file to see how it looked. The result wasn't quite right: MPC-HC played it back with every PGS image shown 2 frames later than they should be. In trying to figure out why that might be, I went back to tsMuxeR to see what the log said. I found this:
Quote:B-pyramid level 1 detected. Shift DTS to 2 frames
Firstly, DTS here doesn't mean DTS audio, it stands for Decode Time Stamps. Secondly, as far as I know, B-pyramid is a concept that relates purely to video streams, not things like PGS or audio. What I'm wondering here is whether tsMuxeR may done something to the h.264 video stream during muxing to have it pull video frames out of buffer 2 frames later than it otherwise would, and to compensate for this, also adjusted the PGS subtitle track (and possibly also the audio track, but I'll get to that in a moment) so that it also displays its images 2 frames later. However, when I played the video back in MPC-HC, I'm guessing (and it's only a semi-educated guess) that it ignores whatever tsMuxeR did to the h.264 stream and just displays the frames as it ordinarily would, but the PGS track *is* delayed by the 2 frames because however tsMuxeR achieves that differs as necessary to apply to the PGS format.
Now... how does that relate to DTS-HD and the 1024 samples of silence? Mostly, probably not much at all. However, it's made me wonder again why that 1024 samples' worth of silence (amounting to roughly half a video frame in duration) are even inserted into the bitstream in the first place. Is it stripped back out during the authoring process, possibly as part of the bitrate smoothing / PBR processing? Or might it be there because of some quirk of hardware decoding that means it actually results in more correct sync compared with the video stream?
5: TL;DR
All of this digging has brought up a lot of questions that I've tried to find answers to with... not a lot of success. I think the main ones are as follows:
- Is the PBR smoothing the reason that a .dtshd stream taken directly from a disc is significantly (~10%) larger than the exact same audio fresh out of the DTS-HD Master Audio Suite encoder? I'm guessing that's exactly it, but it's a guess.
- Although tsMuxeR will quite happily mux .dtshd to a BD folder structure, ISO or .m2ts without a .dtspbr file, which presumably means it isn't doing anything to regulate bitrate spikes in the stream, I expect burning that to disc and playing it back on hardware will result in issues e.g. the audio decoder not reacting quickly enough to the bitrate suddenly increasing and causing artefacts / rendering the output at a lower bitrate than it should. At least, I expect that would be the case for .dtshd from the encoder (e.g. that I've then stripped the header from but not PBR-smoothed). Although...
- Since tsMuxeR doesn't require a .dtspbr file, but a .dtshd stream taken directly from a retail disc will presumably have been already PBR-smoothed during authoring of the original disc, would simply muxing that .dtshd stream (maybe with a delay having been applied) back to a disc result in an already smoothed out audio stream that complies with the Blu-ray Disc standard? Or is it more complex than that? I'm guessing it probably is, otherwise I don't know why you'd need to do the bitrate smoothing process during authoring rather than just doing it beforehand and authoring the result to the disc instead. EDIT: Actually, yeah, I'm forgetting that the total bitrate of video and audio can't exceed the max allowed for a Blu-ray Disc, so presumably that's the reason that the smoothing is not done until the authoring stage. So I guess doing this in tsMuxeR *might* work but it might also mean that the total bitrate is exceeded if your video bitrate and audio bitrate are both very high. I wonder what, if anything, tsMuxeR does to deal with this problem? (For what it's worth, MediaInfo does not report any bitrate info about a solo .dtshd file but if it's muxed into an MKV or something it'll tell you a figure which I assume is just the average bitrate. In the case of Snowpiercer, I found this was about 5.8 Mbps, which is presumably a non-issue seeing as the video bitrate is only about 20-odd Mbps. I believe the total allowed bitrate on a Blu-ray is 54 Mbps (40 Mbps for video), so as long as video + audio are below that, I'm guessing it's fine.)
- Does the 1024 samples' worth (1024 / 512 = 2 DTS frames) of silence added to the start of the .dtshd bitstream by the encoder get removed again during disc authoring, or is it actually supposed to be kept in there to correct for some idiosyncrasy or another? (In other words: should I be manually removing those 1024 samples before authoring or not?) Someone elsewhere has suggested that the DTS Suite header basically tells Scenarist to skip those 2 audio frames, so I think it is effectively removed. CONFIRMED: Yes, it gets removed because the DTS Suite header contains a "codec delay" of 1024 samples.
- If it actually is more accurate to remove the 1024 samples of silence from the start of the bitstream before muxing, will doing so break the DTS Suite header and/or PBR analysis thus causing issues with the bitrate smoothing process that's supposed to happen during disc authoring? (This may not be relevant if the right thing to do is leave it in, if you plan to author with something like Scenarist.) CONFIRMED: Yes, the header contains an instruction to skip the first 1024 frames as mentioned above ("codec delay") so presumably just deleting them and not editing the header would screw this up. But... I wonder if I could remove the silence and also edit the header to remove the codec delay so that the same files could be used with the PBR to author a disc in pro software (i.e. not tsMuxer) *and* to mux into MKV with correct sync (since you can't just mux in the file with the 1024 sample silence to an MKV without it putting sync slightly off).
I know that's a whole lot of words, so I'll understand if nobody wants to read it. But it seems that info on this stuff is very thin on the ground and I'm very interested to know if anybody knows more about it and may be able to answer any or all of the above questions. Even if you do read through all that and have no idea, thank you for giving it a shot nonetheless!
|
|
|
Should audio last (almost) as long as video? |
Posted by: pipefan413 - 2020-05-28, 09:43 PM - Forum: Audio and video editing
- Replies (13)
|
 |
Hi guys,
This probably isn't a big deal but I'm wondering for the purposes of a very very precise sync I'm currently doing (to the level of individual audio samples). I figure if I'm being this accurate I may as well get this bit right. Apologies for the number of calculations here, but it's probably necessary to explain precisely why I'm asking what I'm asking; if you want to cut to the chase and see what the question actually is, I've highlighted it below in bold. Explanation follows from here...
I'm taking an audio stream containing 362,602,496 audio samples at 48 kHz, adding 18,018 samples to sync, and combining it with a custom video stream containing 181393 frames of video. To compare the video length to the audio length very precisely, this number of video frames is equivalent to 181393 / (24000/1001) x 48000 = 363,148,786 audio samples. This means that the custom video outlasts the synced audio by 363,148,786 - (362,602,496 + 18,018) = 528,272 samples, or rather 528,272 / 48000 = 11.005666... seconds.
The audio is from a different video file which contains 181121 frames (equiv. 181121 / (24000/1001) x 48000 = 362,604,242 audio samples). As it appeared there, the audio lasts almost as long as the video, such that there is audio playing during almost every video frame although not all the way through to the end of the last frame (it's a few audio frames short). More precisely, the difference is 362,604,242 - 362,602,496 = 1746 samples, or rather 1746 / 48000 = 0.036375 seconds (36.375 ms). The duration of one video frame is 1 / (24000/1001) = 0.041708333... seconds = 41.708... ms, so the audo stream is still active until the second-to-last video frame, although in practice it's already fallen silent a few seconds before that.
Here's the question, then:
Is there any benefit to adding silence to the end of an audio bitstream in order to more closely match the duration of the video stream it's muxed to, for the purposes of Blu-ray Disc compliance?
If not, I'll just leave it so that the audio track fades to silence then ends shortly after that, then the video (hopefully) will continue playing for another 11 seconds after that. However, I'm wondering if this might cause some software or hardware players to freak out and possibly stop the video once the audio ends; I know some players will do this if the tracks are the other way around (with the video shorter than the audio) but I'm guessing that the video is always prioritised so it may not matter when it's this way round. If it is an issue though, I'll add silence to the end of the audio as follows...
363,148,786 - (362,602,496 + 18,018) = 528272 samples, but I'm encoding with DTS-HD MA which contains a DTS core with 512 samples per frame and 363148786 is not divisible by 512 (363,148,786 / 512 = 709,274.972... audio frames) so I'd round down the audio stream to 709,274 x 512 = 363,148,288 samples. This would make the discrepancy only 363,148,786 - 363,148,288 = 498 audio samples, or in real terms, 498 / 48000 x 1000 = 10.375 ms. That's almost identical to the difference between the original audio and video durations on the source I took the audio from, which may not necessarily be coincidental!
EDIT: Mostly inconsequential but just in case anybody notices and thinks I missed it... I realise that if I just leave the audio as is without adding silence to the end, it's 362,620,514 which isn't divisible by 512 (362,620,514 / 512 = 708,243.19140...). There are two simple solutions to that: either encode it as is and the DTS encoder rounds it up to the nearest whole 512-sample frame, or add samples before encoding to achieve the exact same result. Either way, it'd have 708,244 x 512 = 362,620,928 samples in the audio if I don't add loads more to the end so that it more closely matches the number of video frames.
|
|
|
Choose a dither, or truncate in 20-24 bits? |
Posted by: Falcon - 2020-05-28, 08:38 PM - Forum: Audio and video editing
- Replies (18)
|
 |
I am currently trying to compare the settings of MBit+ on Izotope RX.
My original track is a DTS Cinema Track 16 bits / 44100 Hz, which I slowed down to 44056 Hz, and resampled to 48000.
This generated a 32 bits float track that I need to reduce.
When I zoom in on the audio spectrum, I notice that there is no difference when I truncate to 24 or 20 bits (visually and listening).
When I truncate to 16, I see a difference in the audio spectrum (but I can't hear it).
Your Opinions, or your preferences ?
Dither to 16, or truncate to 24?
|
|
|
RAIDERS OF THE LOST ARK LaserDisc audio gap(s) |
Posted by: pipefan413 - 2020-05-27, 12:11 PM - Forum: Requests, proposals, help
- Replies (11)
|
 |
I watched a restoration of RAIDERS OF THE LOST ARK last night which included audio that I believe was taken from a 1992 LaserDisc PCM rip. For the most part it sounded good, however there are at least 2 film frames' worth of audio missing, and I believe it might actually be as much as 4 frames' worth in total.
The most obvious issue is at a point a few minutes before the 1 hour mark where the audio just drops out completely for 4190 samples of silence (88 milliseconds, just over 2 video frames at this 24000/1001 frame rate). This is after Indy says "that's it" and it cuts to a different shot:
![[Image: vlcsnap-2020-05-27-11h05m33s455.png]](https://i.postimg.cc/HJdQqQT0/vlcsnap-2020-05-27-11h05m33s455.png)
The waveform looks like this in the 48 kHz upsampled LaserDisc track:
![[Image: raiders-ld-gap.png]](https://i.postimg.cc/F7Gmbv79/raiders-ld-gap.png)
I don't know where the reel changes are in this film but it wouldn't surprise me if this was one of them and 2 frames were missing from whatever audio source they had as a result, but they recovered those 2 frames for the LaserDisc video and there was a mismatch. Pure conjecture though, of course. Having said that, I don't think this is a reel change since there aren't any cue marks on nearby frames at least on the litemakr scan I have.
Based on what limited info I have about it, I think the audio shown above is sourced from the 1992 US release LV 1376-WS. Does anybody happen to have access to any other LaserDisc audio sources for Raiders of the Lost Ark that may not have this section missing, either to use for patching, or as a complete replacement? I can patch it with a 35mm optical source if not, but it would probably sound smoother if I used a more similar source.
|
|
|
STAR WARS: ANATOMY OF A DEWBACK (1997) re-framed for 16:9 screens |
Posted by: pipefan413 - 2020-05-26, 03:13 AM - Forum: Released
- Replies (6)
|
 |
This is not a particularly sophisticated project, and indeed although it's watchable I'm not necessarily finished with it. It was basically my first shot at mucking about with AviSynth (with some advice from this forum, actually) because I couldn't see a better way of doing it.
This is the 1997 featurette ANATOMY OF A DEWBACK, about the process of doing ungodly "Special Edition" CGI modifications to the "look sir, droids" sequence in STAR WARS (1977). It was originally released in five very short (~5 min) "episodes" exclusively on the official Star Wars website (and yeah, this was 1997 so it was a really really awful 240p, 24fps RealPlayer stream) and although later released in its entirety on Blu-ray in both 2011 and 2020, they screwed it up pretty badly both times, which annoyed me enough to try to fix it up a bit.
The original 1997 web video is long since deleted, but I kept a recorded copy of the files and recently dug them out to have a look. The video appears to be 320 x 240 pixels (4:3) but this includes black letterboxing; without the letterboxing it’s more like 320 x 192 px, which is a somewhat unusual aspect ratio of 5:3. Although this is the native aspect ratio of 16 mm film, this featurette seems to have been shot on video so it’s probably more significant to note that 5:3 was used in some countries as an early “widescreen” format for a while, presumably as a compromise between theatrical 1.85:1 and 1.33:1 (a.k.a. 4:3) home video. This original version looks something like this, if you crop off the letterboxing from the top and bottom:
![[Image: Wad9yEG.png]](https://i.imgur.com/Wad9yEG.png)
On the 2011 Blu-ray, the featurette was for some reason encoded to display as (almost) 5:3 “widescreen” on a 4:3 television screen. The trouble is, even in 2011, those were a dying breed, and definitely aren’t anywhere near as prevalent in 2020. The result of this is that the vast majority of people will watch this on a 16:9 screen, but the “widescreen” image will not even come close to filling the display on account of being restricted by the 4:3 box. The actual image is a very rough looking 700 x 430 or so pixels, inside a 720 x 540 pixel 4:3 frame. It’s “open matte” to some degree as it hasn’t been framed correctly for this release, but it’s also skewed toward one side, with the left side not cropped enough and the right side slightly over-cropped compared to the old web video. It also appears to have been slightly squashed horizontally. That one looks like this:
![[Image: BvPsCPu.png]](https://i.imgur.com/BvPsCPu.png)
The 2020 Blu-ray is different again, with the image being about 720 x 440 but this time it’s been cropped much more noticeably on the right-hand side than the 2011 transfer was. As a result, it can’t be restored back to an accurate representation of the original framing, and to be honest, it looks like crap overall when compared to the 2011 version. It’s also noticeably stretched horizontally, from less than 700 px (I’m guessing 640 px) to 720 px:
![[Image: mgfxntJ.png]](https://i.imgur.com/mgfxntJ.png)
Since the least cropped (and least aliased) reasonably modern source seems to be the 2011 disc, I cropped and upscaled that (without sharpening the hell out of it) to fill a 16:9 screen, in order to ditch the letterboxing and attempt to fix (as far as possible) the slightly deformed aspect ratio. Since a bit had been cut off the right hand side, I also cropped a little bit off the left to recentre the image, adding equal borders on the left and right to fill a 16:9 screen and upscaling to 720p. Since the source was interlaced, standard definition NTSC, I deinterlaced it with QTGMC. Do not expect this to look like HD footage, because it’s not, and it shows… but it’s a heck of a lot better than the 56k web streaming version and is framed better than either of the official Blu-ray Disc versions as well.
Here’s the 1997 web version with the letterboxing removed, then the remaining frame upscaled to fill a 5:3 frame inside a full-screen 16:9 display, to show what the ideal framing would look like:
![[Image: G4Tlhmu.png]](https://i.imgur.com/G4Tlhmu.png)
Then the same thing but cropped in slightly on all sides to better match the available picture information in the 2011 Blu-ray version (since the 2011 BD version is slightly cropped on the right as well, I cropped in on all sides to restore the original 5:3 aspect ratio):
![[Image: Fn4R0qT.png]](https://i.imgur.com/Fn4R0qT.png)
This was used to work out the most accurate crop and size adjustments for the 2011 video.
The end result is a precisely 5:3 frame with black bars at the sides to fill a 16:9 screen at 720p, instead of a tiny 5:3 frame inside a 4:3 box in the middle (which would have been great when we all used 4:3 TVs but is extremely inconvenient nowadays). It could most definitely look better and the image is still not 100% accurately re-warped to match the exact aspect ratio of the web vid but then it's entirely possible that was wrong in the first place anyway; if I knew more about upscaling and had access to tools like AI sharpening (rather than simple AviSynth filters that create ringing artefacts worse than what you already see below) then perhaps I could achieve better results. I did try just about every resizing filter I could find any info on, and this appeared to be the one that produced the least artefacts. I've also left it in the original BT.601 NTSC colour space rather than outputting BT.709, which may or may not be wise (open to suggestions, would be easy to re-render out BT.709 instead).
Anyway, here's how it ended up after the above:
![[Image: Fl3CWrr.png]](https://i.imgur.com/Fl3CWrr.png)
THIS IS A FAN-MADE PRESERVATION OF BONUS CONTENT FOR A FILM I CARE DEEPLY ABOUT (AND HAVE LEGITIMATELY PURCHASED MANY COPIES OF). I DO NOT ENCOURAGE PIRACY. If you are downloading this, then I consider it a prerequisite that you already own an officially released version of what you are downloading. If you don't, then you should purchase a copy before downloading, as long as that item remains available for purchase. If it has gone out of print, then perhaps a digital copy is available. If no physical or digital copy is available to purchase and you don't already own one, then you are downloading at your own discretion. At time of writing, both the 2011 and 2020 box sets containing this video are still available for purchase.
Furthermore, THE CONTENTS OF THIS DOWNLOAD MUST NOT BE PARTIALLY OR FULLY REPRODUCED FOR PROFIT UNDER ANY CIRCUMSTANCES WHATSOEVER.
Thank you for understanding.
|
|
|
|