Darth Mallwalker

My 'published' script conforms to PAL GOUT.
If you want the NTSC edit, then hacking the script should be trivial:

Change
c68666 = trim(cBlackFilm, 0,-6) # last_frame=68671
to
c68666 = trim(cBlackFilm, 0,-4)

And change
c141781 = trim(cBlackFilm, 0,-1) # last_frame=141781
to
c141781 = trim(cBlackFilm, 0,-2)

Viola! [That's French for violin I think <?> ]
Maybe add more black frames to the end...


You'll void the warranty doing this ;)

nnedi2()

Bob() is out -- replaced with needi2(). Beta script is posted, bug reports welcome.
A few issues are fixed since the Dark-Sega version, and a few still remain.

6458 & 124905
Each of those film frames comprise two video fields; however, the top and bottom fields aren't aligned. They look bad.
Perhaps it's better to discard one field, and let nnedi2() to fill in the blanks.
To try it, simply replace the comment character <#> with a dot.

Script contains 24 instances of nnedi2(). Some are enabled by default, some disabled -- subject to my whim.
Any of them could be turned ON/OFF the same way. Replace <#> with <.> or vice-versa.


We've still got 48 frames repeated as Threepio gets in the bath.
This needs to be fixed, and I'd like your help to determine exactly where in the source video that the reel change occurs.
It's approximately 35226\35227 give or take a field or three. What do you think?

Over the years makeup artists have tried different techniques to hide the scar on Mr. Ford's chin.
This one takes the cake

^That's great news Chew!



It's been my experience that RAR softwares can be stupid about time zones.
If you're bothered by such things, or anal-retentive as I am
then you should pretend you're in Greenwich when you unpack the RARs.
There's a snapshot from my imaginary holiday in Paris (UTC).

File sizes are st00pid too. Add 8GiB to what's shown

^^^Yes, I found a bug.

My script had omitted this field:


If you got the script and want to fix it, here's how.
First replace this line:

c52757 = trim(cBlackFilm, 0,-3) # last_frame=52759

with these:

c52757 = trim(cBlackFilm, 0,-2)
c52759 = \
unalignedSplice(trim(separateFields(trim(cSource, 66342,-1)), 1,-1) \
, trim(separateFields( cBlackVideo ), 2,-1) \
).weave.assumeFPS("ntsc_film")


And then this
cReel04 = cReel04 + c44469+c44470+c52756 + c52757+c52760 # last_frame=55747
becomes
cReel04 = cReel04 + c44469+c44470+c52756 + c52757+c52759+c52760

If you don't like the Weave() look, then you might try something fancy
like NNEDI() for example, to interpolate the missing field....

Consensus has been
NTSC SW & ESB,
PAL ROTJ

I believe G's lastest [published] scripts are that way

Chewtobacca said:

Didn't Japanese NTSC use a different black level from North America?

Not a PAL owner, however I once saw the PAL GOUT at a torrent site.
I didn't download the .VOB files, but I did grab the .IFO files in order to compare the frame count against my NTSC copy.
Opening that file with ifoEdit.exe and I see that it did contain Danish subs (also Swedish, Finnish, Norwegian.)

I suppose it's possible, however unlikely the torrent seeder added those subs.
Seems more likely they're present on the official disc.

Bob(0.0, 1.0)

Coming at the end of Side2, that film frame comprise only one field in the video stream.
So we need to make a deliberate creative decision: weave() or bob() ?
In my script it's defined both ways. The last one wins.
Change the order in the script, or else use a comment character (#) to pick your poison

Yes indeed.
BIG thanks to Arnie.d and Grinder & his no-name friend who all made it happen back in 2009.

It was most generous for Arnie.d to offer those files earlier this year; however it seems nobody was ready to assume responsibility of "project leader".

msycamore wasn't the only one who said might like to tinker with those files.
Mattman mentioned it in another thread, and iirc somebody else too (was it Chewtobacco?) Anyway, the point is
we hope those files will be 'available' for a very long time.
Anybody who wants may have a go at it, and hopefully some good would come out.

I'll offer my AVS script for IVTC'ing progressive frames from the raw video.
Maybe I can offer IVTC'ed clips of certain shots, if they'd be useful for de-SE or de-DNR projects, to save having to download the huge raw files. Ask me

msycamore said:

if I had the raw video files available.

Star.Wars.Holiday.Special.Zion.Hybrid

frank678 said:

Looking at the Tantive Orange Errors Comparisons page the frame that really stood out to me as having the lifelikeness and greater depth of field was from the 1992 FS Dark Jedi Preservation, despite the blur/distortion.

I would love to see even just a clip of this just for comparison if this is still in existence.

If yours are "Extended Play" like the photos, I suppose that means time-compressed for the first two movies.
Would be interesting to find out if they have exactly the same frame count as the time-compressed CED had...

Which laserdiscs you got?
Catalog numbers?

Yikes, glad it didn't start a room fire.
I have a bad habit leaving mine on when I'm out.

Sound like a major setback-- I has a sad to hear it.
Maybe one or more drives will work again in another chasis??? hope :)
Trying to think positive thoughts

AviSynth script for IVTC'ing dark_jedi's "Standard Play" preservation (1130-84)

Here's how it works:


On the left is GOUT frame number, source frame number on right side (because source clip is BFF.)
Of course you can disable the ShowFrameNumber() in the script. Use an editor with a fixed-width font!
If you plan to feed this to an encoder, then mind DGDecode's colorspace conversion (upConv=2) in the first line.

More info Usenet too

Like my earlier JSC script, this one also skips backward in time as Threepio gets in the bath
and again at daybreak when Uncle Owen calls for Luke.
Some of those frames should be replaced by Blackness() but which ones? You decide

144053 was a deliberate creative decision. NTSC GOUT-sync is preserved.
27510 is not my fault

Bug reports will be appreciated

I blame George Kennedy for no-hand Luke's death

Recently when I did IVTC scripts for Dark/Sega SC, I inserted lots of black frames (and black fields too) at reel change points, to achieve GOUT sync.
Maybe have a look in the Dark/Sega thread (or Usenet) to find the script and see how I did it (right or wrong ;)

Or wait until tomorrow, then I'll post the similar script for d_j Standard Play (1130-84) preservation.
Are you planning to include that fullscreen release in your comparison also?

Arnie.d said:

Darth Mallwalker said:

Some players will ignore the flag if you tell them, or allow you to turn CX on/off manually. I don't think my players will allow it.

Probably a stupid question but doesn't your remote have a D/A/CX button?

You skeptics want samples?
hear here

Yes, the 1425-84 reissue by Mitsubishi does contain both analog and digital tracks.
I offered captures of both in Post7 of this thread (I suppose the links are expired by now.)
They sound different, is the message I tried to convey in Post5.
SilverWook mentioned CX decoding in 6, and some time later it 'clicked' in my brain.

If a mastering engineer follows the rule book, then a diGital SOUND track will not have CX encoding applied. The CX logo on the jacket should refer to the analog track only. That's the way it's supposed to work.

But in this case I believe the masterer took the easy route, and didn't follow the rules. I believe this diGital SOUND track really does have CX applied, even though it shouldn't, according to the rules.

I hope you'll help me test that theory. I'll need help because I don't know how to force CX off with either of my players.
Unlike its digital track, I believe that disc's analog track is correctly mastered, which means a flag in the bitstream will tell the player to switch on its CX decoder circuit.
Some players will ignore the flag if you tell them, or allow you to turn CX on/off manually. I don't think my players will allow it.
If somebody can force CX off, and then capture the analog track (without passing through the CX decoder)
then I'll betcha the result would be quite similar to my ripped samples. That's the hypothesis anyway, which I cannot test.

To me the digital track sounds dynamically-challenged or squashed to hell. It's the way the CX compander algorithm works, as I understand it

dark_jedi said:

So can anyone else please verify that the info in this post is correct? Mallwalker do you know for sure?

Arnie.d said:

Darth Mallwalker, do you have plans to rip the audio of the JSC?

^Cool, so that means all the Mitsubishi SWE Trilogy are preserved.
(I got Mitsu ANH in my collection, but not the sequels.)

dark_jedi said:

where exactly do you look on your LD's to find these mint marks and such?

russs15 said:

that looks complicated

russs15 said:

I expect to see a dozen different "rips" available by the weekend.....

schorman13 said:

I'm going to compare the rips to choose whichever is mastered better.

I don't have any RF demod like dark_jedi mentioned. That's only needed for ripping AC3 tracks, and we don't need no stinkin' SE LDs ;)

I still use the same soundcard since page1 of this thread: make M-Audio, model Audiophile2496.
Device driver software and the recording applet are ALSA.
After recording three takes, I use shntool to compare them and make sure they're all three identical (not TOOT).
shntool is one of those things that once you've discovered it, you'll wonder how you ever lived without.

Although you're not expected to remember, I did already mention my player in captainsolo's thread
It's a CLD-S201 bottom-feeder . . . that's got it where it counts.

fly-boy said:

I've made a lot of special modifications myself