Welcome, Guest |
You have to register before you can post on our site.
|
Latest Threads |
Fright Night (1985) Arriv...
Forum: Official and unofficial releases
Last Post: AdmiralNoodles
7 minutes ago
» Replies: 14
» Views: 5,032
|
Bram Stoker's Dracula (19...
Forum: Requests, proposals, help
Last Post: dvdmike
Yesterday, 01:22 PM
» Replies: 7
» Views: 1,733
|
How to use eac3to to edit...
Forum: Audio and video editing
Last Post: ilpubzo5ie
2024-11-24, 02:46 PM
» Replies: 37
» Views: 16,721
|
Laserdisc PCM Capture Gui...
Forum: Capture and rip
Last Post: ilpubzo5ie
2024-11-24, 02:37 PM
» Replies: 140
» Views: 69,010
|
Introduction
Forum: Presentation
Last Post: PixelPlate
2024-11-24, 06:49 AM
» Replies: 0
» Views: 33
|
Kill Bill The Whole Blood...
Forum: Released
Last Post: PixelPlate
2024-11-24, 06:46 AM
» Replies: 8
» Views: 3,904
|
Hi
Forum: Presentation
Last Post: athomasm1
2024-11-24, 12:11 AM
» Replies: 0
» Views: 31
|
Kill Bill Vol. 1 & 2 UNCU...
Forum: In progress
Last Post: SHN_TRU_92
2024-11-23, 09:31 PM
» Replies: 15
» Views: 7,246
|
No Time To Die (IMAX/Open...
Forum: Released
Last Post: Hitcher
2024-11-23, 05:51 PM
» Replies: 18
» Views: 894
|
Highlander II - European ...
Forum: Released
Last Post: el_hache
2024-11-23, 09:07 AM
» Replies: 96
» Views: 51,153
|
|
|
Hello there! |
Posted by: Arjak - 2020-05-30, 01:55 AM - Forum: Presentation
- Replies (1)
|
|
Hello, everyone! You can call me Arjak. I'm a huge fanatic of classic films and video games. I recently discovered this place in my search for the infamous theatrical cut of Highlander 2, and my searches eventually led me to discover this fine place. Thanks, HippieDalek!
I hope that I will get along with all of you, that my time here will lead to new friends and knowledge, and that I can continue to share in the appreciation for film and its history with all of you.
Very nice to meet you all!
|
|
|
Return of the Living Dead (1985) theatrical reconstruction |
Posted by: Evit - 2020-05-30, 01:27 AM - Forum: Released
- Replies (14)
|
|
After long waiting (the idea came to crampedmisfit1990 on 6th June 2018), here comes Return of the Living Dead (1985) in a theatrical reconstruction made from the best available sources.
In 2016 Shout Factory Blu-Ray put previous releases to shame thanks to a recent transfer that featured a more defined image, correct proportions and no cropped framing (comparison shots with previous 2012 UK release by Second Sight can be seen on caps-a-holic). However, the soundtrack was slightly changed and end credits were changed accordingly, some lines of dialogue have been re-recorded (tar man has a different voice and the "send more cops" line has been redubbed), not to mention the Orion logo that had vanished long before the Blu-Ray format, replaced by MGM and their roaring lion.
The idea was to take the best video from Shout Factory, replace that end credits entry, restore the original soundtrack (from Second Sight Blu-Ray), but while we were at it, I brought the whole film back to 1985!
LIST OF FEATURES
- Intro with 1985 Orion logo restored, replacing MGM logo
- End credits fixed with "Dead Beat Dance" restored (thanks Leonardo!)
- R rating outro in HD as seen in the theaters after the end credits
- MGM roar sound removed from intro and end.
- No re-encode involved (only smart rendering of the connecting parts)
- Original and new sound mixes + US Laserdisc audio (thanks to Bronan)
Release format: MKV 1080p 25GB, Bitrate 34 Mb/s.
Audio
1. US Laserdisc Original Mono 2.0 (PCM)
2. Original Mono 2.0 (PCM)
3. 2002 Remix 2.0 (PCM)
4. Audio commentary with Gary Smart, co-author of The Complete History of The Return of the Living Dead, and Chris Griffiths (2016) (AC3)
5. Audio commentary with Actors Thom Mathews, John Philbin and Make-Up Effects Artist Tony Gardner (2016) (AC3)
6. Audio commentary with Director Dan O'Bannon and Production Designer William Stout (AC3)
7. Audio commentary with the Cast and Crew (William Stout, Don Calfa, Linnea Quigley, Brian Peck, Beverly Randolph, Allan Trautman) (AC3)
Note: the only missing audio is the 2002 remix in 5.1 DTS-HD. I don't know how to work with that format (the MGM lion roar has to be removed) so if anyone wants to take a shot at it, feel free to take this and remux it by adding a synched 5.1 track. Since this is a theatrical reconstruction the modern remix is an more of an afterthought to be honest. Same goes with foreign dubs, unless you find theatrical mixes of those too.
Subtitles
1. English SDH
2. Zombie subtitles (just a lot of "aaaaargh!!!")
3. In their words - the zombies speak! (zombies are subtitled in English, hilariously I should add)
SOURCES
Based on Shout Factory BR release 2016
Original audio and end credits replacement from Second Sight BR release 2012
Orion logo from Robocop Blu-Ray
US Laserdisc for additional audio track
Thanks to
Beber
Bronan
crampedmisfit1990
Leonardo (for fixing the end credits)
SpaceBlackKnight
I hope I'm not forgetting anyone, it has been a long-running project.
PM for links. Active members of the forum only.
It's up on the Spleen too, for whoever has access to that.
|
|
|
Highlander II - 35mm Grindhouse Edition |
Posted by: HippieDalek - 2020-05-29, 08:32 PM - Forum: Released
- Replies (57)
|
|
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.
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?
|
|
|
|