Jan

Williarob said:

jedimasterobiwan said:

i was playing the video but the image was a still and i only heard audio does that mean my computer is to slow to play it?

Possibly, though trying a different player might fix it.

Can you recommend a particular player for Mac OS? I’m currently using MPlayer X on my MacBook Pro from 2012. As HEVC decoding is done solely on the CPU, playback is nowhere near realtime (more like 5-6 FPS). Or would you mind uploading future videos in 1080p H264 as well?

Sounds awesome Harmy, I’m really looking forward to both ROTJ Despecialized and the 35mm Gridhouse version. What would you say, is the Grindhouse version roughly on the same level of quality as ESB Grindhouse regarding stabilization, cleanup etc? And will TN1 use the same scan of the same LPP print to do a more cleaned up restauration later on?

RU.08 said:

Jan said:

2. In my opinion, a total size of about 25GB is sufficient for a 1080p encode at a very good quality (just compare it to encodes of other movies available on various file sharing sites), if the encoding settings were to be somewhat enhanced compared to your V1.0. As you’re aiming for a final file size, 2pass encoding fits the purpose much better than CRF. Additionally, some other settings might need adjustments. Overall, the settings suggested at the official x264 website (see link below) are quite a good starting point. The one thing I would change though is --tune grain instead of --tune film for obvious reasons. Any other possible, manual change of the encoding settings is just fine-tuning in my point of view. With these settings, the encoding quality will be quite a bit better and fine details as well as grain will be be preserved much better! BTW, I helped Harmy with his encodes of the Despecialized Edition😃

Hi Jan, sorry to say you’re wrong on this one. The best h264 commercially available encoders are about 40% more efficient than x264. And I’m not talking about Mainconcept which is the encoder everyone compares x264 to, I’m talking about Sirius Pixels which is much better than x264, hence the reason that top authoring houses prefer it. So if you have a Bluray that’s already encoded using the Sirius Pixels encoder then no matter what you do, the x264 encode will be significantly lower quality at the same size (beyond just the generational loss). A single-layer movie encoded using the Sirius Pixels encoder can match the quality of a double-layer movie encoded using Mainconcept or x264. Also, the 2pass option does not produce better quality at the same size as CRF.

Additionally, movies are made more compressible before encoding as well. Such as removing film grain - especially in the effects shots.

With this release we have neither option - the -1 team don’t have access to the best encoders (and if they do they don’t want us to know), and they want to release the film as it is, and not cleaned up to a point that makes it much more compressible. So in my view it’s not the x264 settings that are an issue, rather it’s the CRF value itself. In this case, CRF = 19, which is just not quite good enough, and leads to visible compression artefacts, at least in some parts of the movie. If it were up to me, which it isn’t as I’m not a part of their team, I’d suggest a CRF value of 16. This might result in a 34-50GB file size, but I’d personally rather see that.

Yes it is much larger, but we have a v1.0 now so I say go all out for v1.5 and so I say: let the material truly shine!

Also: many thanks to the Team -1 - what a terrific effort with this release!!

V

Hi Ru.08, I’ll just use your post as a reference to the discussion about encoders and encoding settings that has been going on on the last two pages.

First of all, I have never heard of that Sirius Pixels encoder and a quick Google search did not bring up any comparision to x264, so do you have any source proofing that it’s really 40% better? That would be an extremly high margin among two encoders using the same codec. Actually, the first thought that came to my mind is that you’re comparing an HEVC (H265) encoder to an AVC (H264) encoder. Then the significant difference in quality at the same file size would make sense.

Here are some basic rules about quality vs. file size vs. encoding settings (subme, reference frames etc.):

• Yes, CRF and 2pass result in the same quality at a given file size. However, the two encoding modes are tailored for completely different purposes. When using CRF, the goal really is to achieve a certain quality (represented by the CRF value) irregardless of the file size! With 2pass the filesize/bitrate is given and the encoder tries to distribute the bits in an optimal way to achieve the best possible quality at that very filesize. Here the encoding settings are crutial. I hope it’s clear now why it’s reasonable to use 2pass for a Bluray encode.
• A given CRF will always result in the same quality. If you use better encoding settings though, the encoder distributes the bits more efficiently (so to say), resulting in a smaller file size. The enconding time however increases.
• When using 2pass, the filesize is fixed, hence better encoding settings lead to a better overall quality. The enconding time however increases.

This is why I think it would make sense to use more optimised encoding settings for the upcoming BD release of Star Wars and ESB.

The basic question really is how many frames there are missing at each cutpoint and where exactly. Somewhere in the middle of a scene or at its end or beginning?

If there are only a few frames missing and they are located in the middle of a scene and not too complex overall, it might be possible to recreate them using some kind of algorithm based on motion estimation. Now, my knowledge in this area is quite limited, so I have no idea how advanced these tools are and whether this can be done without visible artifacts.

I don’t know if this rate extending concept in Premiere that towne32 suggested is something similar. I have never even touched Premiere.

Inserting upscaled Gout frames might very well be visible when playing the movie back, as will black frames if too many of them occur in a row. Not sure about duplicated frames, might be worth a try.

As far as I know Mike Verta does not intend to release his restauration to the public, or at least not in the same way as Team Negative1 just did. Him being a very prominent member of the movie industry, doing this could lead to very significant consequences for him.

It is possible to sync TN1’s restauration with the GOUT near losslessly by only reencoding a few frames around the cutting points. This is not trivial on the technical side though (the way H264 compresses videos is the reason for it), and therefore only a few video editors are able to do this so called “Smart Encoding” without issues. SmartCutter is probably the best one.

First and foremost, congratulations and thank you very very much to Team Negative1 and everyone else involved in this preservation. It truely is a remarkable achievement. When I first heard of this project, I would never have expected that the final result/quality would be anywhere near what you’ve put out. Most amazing! Somehow, I wish your preservation would be the official Bluray instead of the mediocre shit that Lucas released.

I haven’t had a chance to watch to whole movie yet, but I’d still like to suggest two possible improvements for the upcoming V1.5 release.

1. Please lower the volume of the intro you added a bit, it’s considerably louder that the actual movie😉
2. In my opinion, a total size of about 25GB is sufficient for a 1080p encode at a very good quality (just compare it to encodes of other movies available on various file sharing sites), if the encoding settings were to be somewhat enhanced compared to your V1.0. As you’re aiming for a final file size, 2pass encoding fits the purpose much better than CRF. Additionally, some other settings might need adjustments. Overall, the settings suggested at the official x264 website (see link below) are quite a good starting point. The one thing I would change though is --tune grain instead of --tune film for obvious reasons. Any other possible, manual change of the encoding settings is just fine-tuning in my point of view. With these settings, the encoding quality will be quite a bit better and fine details as well as grain will be be preserved much better! BTW, I helped Harmy with his encodes of the Despecialized Edition😃

http://www.x264bluray.com/home/1080i-p

team_negative1 said:

There is no current blog, or additions to the email list. That was for prior members from our past blog.

As far as the previews go, those were limited in time also. Members here will share them with you, feel free to PM them.

Team Negative1

So, how can I get my hands on the preview of reel 3 that you shared via mail at the end of November? Unfortunately the link was already dead before I had the chance to grab it.

Happy new year everyone, of course!

Media Player Classic Home Cinema should be able to do so.

Great workprint, I absolutely admire the work you guys put into restoring Star Wars and I think it clearly shows how great of a cleanup you did on the movie. Can't wait to see the final result:-)

However, I agree with Harmy on the matter of compression artifacts. There's so much blocking not only in dark scenes like the one in the canyon, but rather throughout the whole workprint, so much that it "eats up" a lot of the grain structure that would otherwise probably be visible.

By looking at the encoding settings (MediaInfo can do that) it is obvious that encoding speed has been a major goal, which comes as no surprise considering this is just a workprint. However, the settings could have been significantly optimised to achieve a better quality with less blocking and yet without a drastic slowdown. F.e. encoding with 1-pass constant bitrate as you did is much inferior to CRF mode quality-wise.

Quite a nice machine Harmy:-) I'd have chosen a SSD as system drive though. If you ever had one you'd never want to go back to HDDs.

Year, 32bit software has a RAM limitation of 2GB per process, which is quite easily maxed out when encoding HD with a few Avisynth filters or slow x264 settings (especially lookahead and merange).

As I said earlier, the whole encoding process should be about 20% faster when using 64bit for Avisynth and x264, so it's probably worth to switch. I can check whether all filters are available in 64bit if you PM me your script.

Year I imagined that;-) If you encode a number of movies it might be worth to go to 64bit though as I think it's about 20% faster.

Encoding in 64bit is unfortunately not as straight forward as replacing x264.exe with a 64bit build. There's basically two ways as far as I know:

1) Avisynth 64bit + x264 64bit

Pros: No 2GB memory limitation for Avisynth, speed

Cons: Only 64bit Avisynth filters

2) Avisynth 32bit + avs2pipe or avs2yuv + x264 64bit

Pros: 32bit Avisynth filters are useable (if needed)

As I only encoded in 32bit so far my knowledge on this is rather limited. I hope that's enough to manage the rest via Google search.

Hey Harmy,

year, I'm still around, though I have had very little time lately due to university stuff going on. Unfortunately it'll probably stay like this until mid of May at least. I'll see if I can help you with improving the script, but I can't really make any promises, sorry.

Congrats to your new PC;-) What kind of specs does it have?

I've just taken a look at the comparison pics you posted. Honestly I can't remember if SW AVCHD looked considerably better. Did it?

Anyway, as a first thing change "--preset slow" to "--preset slower --subme 10". It will slow down the encode considerably, but quality should improve. You can also try "--me esa" instead of "--me umh", but don't expect too much here. I don't think that's enough though as probably x264 options have changed over time and the command line should be adjusted to those changes. I also think that settings like pay-rd, aq and deblock should be fine-tuned to the differing grain structure etc. of SW and ESB. That however needs a lot of test encodes.

Regards Jan

Edit: One thing that just came to my mind is your rendering/encoding process. Do you have a lossless intermediate of some kind and then encode using x264.exe? Or does all that happen within the Adobe software?

If you're talking about the mkv, it uses the password given here. Not sure about the AVCHD though.

The gallery really shows how much work and dedication you put into this project Harmy and of course how amazing the result is :-)

I've seen 5.1 DTS-HD MA tracks varying in size from like 1.5 GB to more than 4 GB for 2 hour movies.

Just to let you guys know: As there'll be version 2.1 of the AVCHD coming up, I'll probably only upload this one to usenet and not version 2.0

Oldfan said:

Thanks for answering my questions about the confusion.

I take it then that "Harmy_DeEd_v2_h_h_5.1_fixed" is the new fixed 5.1 audio track? It looks like it's still being uploaded if that's the track I want.

I don't know what it is. Hairy_hen did not even release the fixed track, did he? So it can't be that I guess. Plus almost 4GB have been uploaded so far, which means it's likely to include a video track as well. Unfortunately the guy uploading it didn't supply an nfo file.

Oldfan said:

And does this: Fixed_DeEdv2.0

already include the corrected German and Spanish Soundtracks?

No it doesn't. You need to download "DeEd2.0_Fixed_Spanish_Dub.ac3" and "DeEd2.0_Fixed_German_Dub.ac3" as well.

Restarting JD helped on my end. If it doesn't wait a few hours until the overall load on uloz.to is lower.

Nice :-) Unfortunately uloz.to offers hardly any download slots for free users on weekends, so downloading it will probably take some time.

By the way, the screenshots I posted some pages earlier were from a test encode at the lower bitrate.

doubleofive said:

Skipped around the MKV, looks great! Is there going to be a Harmy-released AVCHD, or should I used my IT skills to make one of my own?

Scroll up a few posts and you'll see screenshots of the official AVCHD ;-)

I see. Well, you could try it of course. If you want I can help you with the settings once you come to that point. 

Viel Glück für dein Projekt!

Laserschwert said:

Jan said:

Ok, here are a few screenshots comparing the quality of both BD/MKV and AVCHD to the Lossless Source.

 

The AVCHD looks really great... do you think that quality could be achieved if I re-encode the MKV video to 15000kbps again?

Generally I don't recommend doing such a thing and honestly I can't see why you want to. Output quality will largely depend on the encoding settings as will speed. I guess you could achieve the AVCHD quality or even better in such a scenario if you used optimal, but also very slow settings which are carefully adjusted.