How to adapt a18fps film to 25fps video?

[papcom]

Ich have frame by frame scanned 8mm film which originally runs in 16 or 18 fps. Now I want to adapt this filmtransfer to 25fps in order to use the mpeg2 file for a PAL DVD.- I already tried a lot but nothing gave me a satisfying result.

What would be the perfect code which would do this Job? ... a function, plugin, etc.? - thank You for Your well estimated help.

[johnmeyer]

This is the usual script for adding pulldown fields to film so that it can be played on a standard TV set at 25 fps (edited to add weave() statement):
ChangeFPS(50,1)
AssumeBFF() # or TFF, as required
SeparateFields()
SelectEvery(4, 0, 3)
weave()This will create interlaced 25 fps PAL video.

I do lots of film transfers and do NOT like using motion estimation to change frame rates because it introduces too many artifacts.

Do a test, using this script, and look at the final result of your 5-10 second test clip, field-by-field, to make sure that you didn't get field reversal. If you do, you'll need to change the SelectEvery() statement.

[papcom]

thank You @johnmeyer - I am just testing the code. Why is the Picture half the Resolution (288 instead of 576 Pixel).. (must have sth to do with the interlacing?) ...and how do I set for 18fps and for 16 fps film- speed?

[StainlessS]

Perhaps a Weave at the end ?

[papcom]

thanks @stainlesss, "weave" has done it. In the meantime I have checked the description about the FPS filter. Unfortunately I do not yet understand the relation between the speed of the endresult and the Settings: When is it 16 fps and when is it 18fps?

My script Looks now like this, and it has the same Speed as the the source Video, which is a 25 fps progressive QT MOV (each frame respresents a Frame of the film):

QTInput("C:\testfilm_.mov") .FlipHorizontal()

ChangeFPS(50,1)
AssumeTFF() # or BFF, as required
SeparateFields()
SelectEvery(4, 0, 3)
Weave()


Now I am looking for the method to alter this 25fps progressive source video in order to get a new 25 fps Video with a "18 fps playspeed". ( iot has to add some Frames somehow)

[johnmeyer]

Perhaps a Weave at the end ?Yes, you are right. I cut/pasted from a larger script, and the weave() statement was further down in the script.

I corrected my initial post to add the statement. It should work correctly now.

[johnmeyer]

thanks @stainlesss, "weave" has done it. In the meantime I have checked the description about the FPS filter. Unfortunately I do not yet understand the relation between the speed of the endresult and the Settings: When is it 16 fps and when is it 18fps?I may not be understanding what you are asking, but here is my answer to what I think is your question.

The frames per second that the video actually plays at can be changed with an AssumeFPS() statement. Unlike the script fragment I posted, which uses ChangeFPS(), AssumeFPS does not change the video in any way at all, but simply causes the frames to be played more quickly or more slowly. It is identical to what you get with an old movie projector when you rotate the speed knob, and the projector speeds up or slows down: the same frames are put through the projector, but the motion either speeds up or slows down.

By contrast, the script I posted adds additional, duplicated fields to the video (although the pixels in each field are not altered in any way). When the resulting video is then played on a device that is hard-wired to play frames at a faster speed than the original video (25 fps instead of 16 or 18 fps), the apparent motion will be identical to the original film running at its original 16 or 18 frames per second speed.

[edit]You were updating your post as I was writing the above. If you are asking what changes need to be made for 16 fps vs. 18 fps, the answer is no change needs to be made. As long as the film frame rate is correctly reported to AVISynth, the ChangeFPS() statement will add the correct number of fields to achieve a 25 fps final result. [/end edit]

[papcom]

principally my 25fps source Video has to be slowed down to 18 pfs. (but anyhow play with 25fps !). Theoretically this is done by duplicating some frames. But this procedure results in slightly stuttering Videos, the more you go down with the framerate. I am searching for a process that does this kind of procedure smoothly with a high quality result, and the end Video is a 25fps interlaced Video, that I can use to encode my MPEG2 for DVD.

[johnmeyer]

principally my 25fps source Video has to be slowed down to 18 pfs. (but anyhow play with 25fps !). Theoretically this is done by duplicating some frames. But this procedure results in slightly stuttering Videos, the more you go down with the framerate. I am searching for a process that does this kind of procedure smoothly with a high quality result, and the end Video is a 25fps interlaced Video, that I can use to encode my MPEG2 for DVD.I don't understand at all what you are saying. I thought you had 16 or 18 fps source material (e.g., silent movie film). Now you are saying that you are slowing down 25 fps video to 18 fps.

I don't understand what you are trying to do, and therefore my original script is probably not what you want to use.

[creaothceann]

I think he got a 18fps source whose playback speed is set to 25fps. In that case the first command in Avisynth would be the AssumeFPS call.

>slightly stuttering Videos [sic], the more you go down with the framerate

Easy: don't use DVDs. VFR (variable frame rate) files are best if you care about quality.

[papcom]

OK I explain it more detailed what I have:

A 8mm film was transferred on a system frame by frame. The facility then gave me a standard pal video running at 25fps (as usual for PAL), where every of the the videoframes correspond to a filmframe. When I run this progressive video I can see the film but it runs too fast because the original filmmaterial was shot in 18 fps and now plays with 25fps. Principally no problem. I could change framerate of the video in a frameratechanger tool in oder the video plays in 18 fps. But this only works on PC platforms and not in a broadcast or DVD environment

So when it comes to the situation that I have to make a PAL DVD then I need an video which runs in 25fps, but showing the 18fps film. The same would occur when I send a broadcast copy to the TV station which transmits video in 25 fps.

[johnmeyer]

OK, I now understand.

For playing on a computer, just change the header (easy to do for AVI and, i assume, for MOV). No need to re-encode.

To end up with a 25 fps PAL video, use the script I already posted, but add AssumeFPS(18) or AssumeFPS(16) at the beginning of the script.

As for variable frame rate, that is an awful solution to almost any problem. It certainly would be the wrong thing to do for this workflow.

[TheSkiller]

You can also do a soft-pulldown using DGPulldown. The result is the same as the ChangeFPS script by johnmeyer, except that the field repeats are not encoded but are applied during playback (yes, it's fully DVD compliant) yielding better encoding efficacy because only the core 18 or 16 fps are encoded without the field repeats.

[johnmeyer]

You can also do a soft-pulldown using DGPulldown. The result is the same as the ChangeFPS script by johnmeyer, except that the field repeats are not encoded but are applied during playback (yes, it's fully DVD compliant) yielding better encoding efficacy because only the core 18 or 16 fps are encoded without the field repeats.I remember learning about this a few months ago and, at first, didn't think it would work. It does work, but I seem to remember that there is a limit as to how large a shift can be made. I think I was trying to go all the way to 29.97, not 25, so that may be why I remember the limitation.

Can you go all the way from 16 to 25, or only from 18 to 25? I'm pretty certain you can't use this trick to get from 16 to 29.97.

[foxyshadis]

The maximum you can go up with soft pulldown is 50% speedup (where every single frame has one field repeated). Beyond that you'd have to use hard pulldown, or a combination of hard and soft. 16 to 25 would be just a hair too much, but gently nudging it up to 16.7 fps would work. (Same ratio as 24->25 PAL speedup.)

[papcom]

@johnmeyer - what do You use as source video format (re 18fps filmtransfer)?

[johnmeyer]

@johnmeyer - what do You use as source video format (re 18fps filmtransfer)?I do all my 8mm and Super 8 film transfers with the DV AVI codec, using the MainConcept DV version of that codec which permits arbitrary frame rates (i.e., it is not hard-wired to 25 and 29.97 fps). DV is a great codec because the MainConcept (and Sony) versions introduce virtually no additional compression artifacts, even if you have to render more than one generation. More important, the timeline performance in my NLE (Sony Vegas) is faster than any other codec. The downside of 4:1:1 color space is generally not an issue with amateur film, which usually doesn't have very good color to begin with.

I have to manually override the DV interlace flagto tell my NLE that the frame-accurate film capture is progressive, but I have written some Sony Vegas scripts that do that for all clips at the push of one button.

I have done some experimentation with various HD capture formats, but haven't yet made the considerable investment in equipment to permit frame-accurate HD capture. There is no point in it for my 8mm and Super 8 captures, but I would definitely get a little quality improvement for my 16mm work.

[feisty2]

DV..? Seriously, I can tell hell lot of artifacts from this ancient codec, I think even mjpeg would be better than this, 21st century, time to update
Pick some more recent codecs, prores or dnxhd and personally, uncompressed image sequences should be the first choice I guess, they are very fast and zero quality loss

[creaothceann]

uncompressed
*lossless-compressed

[johnmeyer]

DV..? Seriously, I can tell hell lot of artifacts from this ancient codec, I think even mjpeg would be better than this, 21st century, time to update
Pick some more recent codecs, prores or dnxhd and personally, uncompressed image sequences should be the first choice I guess, they are very fast and zero quality lossChoosing a codec involves many more considerations beyond the issue of artifacts. No matter what codec choice I might make, every one of them -- even uncompressed -- involves loss and artifacts when the original source is analog. Film is analog, meaning that is has to be digitized. The act of digitization ("capture") introduces far more problems than the next step of putting that digitized video into some sort of container, with or without some form of compression.

The biggest advantage of DV is that the capture tools are flawless and bulletproof compared to most capture cards. Nothing else comes close to the reliability of DV capture. True, when everything is working right, capture cards can provide better quality, but in my experience, I have always had problems with capture cards dropping frames.

So, having critically looked at a lot of video, frame-by-frame and field-by-field, the issues of compression artifacts are nothing compared to how the film is captured and then digitized.

Using DV never lets me down, and never causes me to have to go back and re-capture. This is HUGE. I'm sure you have found that re-capturing an analog video tape is a PIA, but it is nothing compared to having to re-capture film. Why? Because you have to haul out the film, re-thread the transfer machine, re-align the capture equipment and, in the case of my equipment, re-do that capture at the 1/3 real time speed that a frame-by-frame capture requires on my "Workprinter."

So, while I don't disagree at all with your assessment of the DV codec, my choice to use that codec is based on lots of more important considerations than compression artifacts. All the other workflow considerations completely trump that one downside.

[feisty2]

guess you are talking about a "DVR device" works and "capture cards" don't, but that's not the point, I was just saying "DV Codec" is bad, so, your DVR offers no other codec choice besides DV?

[johnmeyer]

guess you are talking about a "DVR device" works and "capture cards" don't, but that's not the point, I was just saying "DV Codec" is bad, so, your DVR offers no other codec choice besides DV?I think you are confused. No DVR that I know of uses the DV codec. The only similarity between DV and DVR is that they both contain the letters "DV."

DV Video (http://en.wikipedia.org/wiki/DV) was the key, essential invention that made consumer digital video possible. Prior to its invention, video was digitized using very slow, very expensive technology which required RAID disk drives just to be able to deliver the huge number of bits per second required by the almost-uncompressed video formats of the early, pre-1995, digital video era.

DV was invented by a large number of engineers, each employed by different camera companies, working together. It is the product of some of the best minds to ever tackle the problem of digitizing video. While there are other video standards, such as H.264 and MPEG-2, those have dozens of variations and permutations, and not all applications work with all variations (e.g., VideoRedo chokes on certain types of H.264 files).

By contrast, DV video is a singular standard, with no variations. I'm not sure any other codec is like that. What this means is that when you use DV video, everything always works.

DV's other main advantage is that all the compression, as well as the A/D conversion when importing from external analog formats, is done via hard-wired firmware in the camera or capture device. And here's the key thing: this stuff is bulletproof. It works every time.

To be clear, I am talking about the capture portion of the DV setup. All codecs "work every time" when you feed them some video to encode, but many become very problematic when embedded into a capture workflow. When using MPEG-2, MJPEG, and various proprietary capture formats, I have experienced all manner of problems, including dropped frames, audio sync issues, field reversal, unexpected IVTC, and audio volume problems.

In addition, when using DV, the video is transferred into the computer via Firewire/1394, another technology that was developed as an industry standard and therefore, like USB, works across all different computers and devices. It works every time.

Finally, you are absolutely correct that the DV technology is old (introduced in 1995). However, that does not necessarily mean that it is obsolete, or that newer codec technology is necessarily a better choice for every application. This is similar to the audio CD which was introduced in 1984, which still sounds better than any MP3 player can ever hope to sound.

Most codec developments during the past twenty years have been created to address issues other than compression artifacts. In fact, most of the modern codecs use inter-frame compression rather than intra-frame compression and as a result produce a lot of artifacting. So, while there are lots of newer codecs, some were designed to facilitate streaming; some were designed to provide huge compression ratios for small screens and portable devices; and others were created to help exchange pirated movies (DivX). Some codecs were designed for capture (AVCHD); others for delivery (MPEG2); and still others for editing (like Cineform).

As I stated before, the codec choice for any application involves a lot of engineering tradeoffs, and requires consideing a lot of more than compression artifacts. Every lossy codec produces compression artifacts, but for a lot of applications those artifacts are not that severe compared to other issues I've described here.

[feisty2]

well, I'm still confused, DV is before my time indeed, it was launched even before I was born, the very first thing I know that is called "video" is a DVD (MPEG2) when I was a kid, then Bluray.
I do know nothing about DV stuff, but I wanna get to know some

This is similar to the audio CD which was introduced in 1984, which still sounds better than any MP3 player can ever hope to sound.

I know that much, but c'mon man, CDDA is LPCM (uncompressed) while .mp3 files are lossily compressed, you can't do compares like that, I could say the even older uncompressed video is much more quality-wise than DV, right? a fair compare is like a compare between DV and ProRes


Most codec developments during the past twenty years have been created to address issues other than compression artifacts. In fact, most of the modern codecs use inter-frame compression rather than intra-frame compression and as a result produce a lot of artifacting. So, while there are lots of newer codecs, some were designed to facilitate streaming; some were designed to provide huge compression ratios for small screens and portable devices; and others were created to help exchange pirated movies (DivX). Some codecs were designed for capture (AVCHD); others for delivery (MPEG2); and still others for editing (like Cineform).

yeah, I know the basics about codecs, and codecs are indeed designed to overcome artifacts somehow (see "SAO", a hevc feature to kill ringings and bandings), and inter frame compression is not the answer to artifacts, if you want it to work like intra frame compression (constant quality between frames), it can do, just set the encoding mode to "Constant Quantization" and you get the constant quality while it offers a better compression ratio to those intra ones

anyways, I gotta go out now, will get back to this when I got home

[foxyshadis]

DV isn't really so bad. I mean, you can find bad DV, but 720x480x30 @ 25mbps isn't anything to sneeze at. Like johnmeyer says, the 4:1:1 sucks for chroma... if you're starting from a good source. An old VHS or super8 film transfer doesn't even have close to full DVD resolution in the first place, so the downsampling isn't that big of a deal. Where DV really starts to suck is in re-encoding repeatedly, an unfortunately common workflow in the past, but now it's easy enough to work off of an original master.

Since DVCPRO codecs can use 4:2:0 and more than 25mbps, so that'd obviously be useful if available, but even if not, one generation of DV isn't that horrible.

And when he talks about capturing flawlessly, he means by some hardware encoder, like a video camera, not anything PC based at all. I don't have quite that much faith in hardware recorders, but they definitely never have interactions with software problems.

[feisty2]

DV isn't really so bad. I mean, you can find bad DV, but 720x480x30 @ 25mbps isn't anything to sneeze at.

it's bad, really, I did a test before, got a 2k tiff sequence resized to 720x486 then encoded with QuickTime to a ProRes video (4:2:2 10bits APCN) and it's only 26.9 Mbps and visually lossless compared to the resized only sequence, no visible detail loss, no visible artifacts at all

and the same sequence, encoded to DV codec with QuickTime, I'll just put 4:1:1 and detail loss aside for now cuz they are only disasters, and one more "catastrophe" left, it's the compression artifacts, the encoded clip is filled up with A LOT OF mosquito noise, I mean, yeah, even a decent quality DVD got a far better image quality than that destroyed clip, and there's only one to blame, DV codec, it's almost large as ProRes (25 Mbps ) and the quality is far far worse than ProRes

[johnmeyer]

Two quick things:

1. As I said in each previous post, the reason I choose DV for VHS and film transfers are all the other parts of the workflow. As Foxy correctly points out, the 4:1:1 issue is the biggest issue with this format. However, the equipment designed around DV is bulletproof, and the timeline playback is smoother than any other codec. This more than makes up for any codec deficiencies, especially when dealing with VHS/Beta/8mm video and when doing 8mm and Super 8 film transfers.

2. Multi-generation losses depends on the encoder. While decoding is always done the same, the encoding quality can be quite different. The Sony DV codec, built into Sony Vegas, is absolutely amazing. We did tests twelve years ago over in the Sony forum, and the Sony DV codec stood up well after over a dozen re-encodes (the test was done all the way to generation 100):

Multi-generation DV render test (http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=235382)

If you read any of that thread, you'll find that the Microsoft DV codec, built into Windows, was (is) absolute garbage. If that is what you've been using, then I would definitely agree that DV is awful and should never be used.

[feisty2]

http://www.sonycreativesoftware.com/Forums/ShowMessage.asp?Forum=4&MessageID=239236
I was talking about this, it still happens with Sony DV codec, but never appears on ProRes vids

[papcom]

@johnmeyer - my question for the source format was directed to the framerate of Your sourcefiles when You are using Your script (filmtransfer 16fps or 18fps)?

As stated before, I am always using 25fps videofiles (progressive, prores422-HQ) coming from a frame by frame transfer, where every videoframe represents a frame of the filme.

For the end-result I am searching for a smooth running 25fps Video (interlaced) which plays the transferred film at its original speed (18fps or 16 fps) for broadcasting in television or on a PAL DVD.

[johnmeyer]

@johnmeyer - my question for the source format was directed to the framerate of Your sourcefiles when You are using Your script (filmtransfer 16fps or 18fps)?Since my video is captured using DV, it is in an AVI wrapper. I use an old utility, AVIFrate, to change the playback speed in the header of the AVI file to match what I guess is the correct playback speed for the original film. Since my capture equipment is frame accurate, this is identical to what you get by changing the speed of the movie film projector.

Once the speed is correct, everything else in the workflow "falls into place" and there are no surprises, such as the ones you experienced when you ended up with the wrong speed, or too many duplicated fields. I highly recommend this method. If you don't want to use the DV AVI codec, then you can use a codec that has virtually no drawbacks, namely Cineform. It costs $$, but it is about as good as it gets.

BTW, film speed is NOT a known quantity. Most amateur silent film was shot on cameras that did not conform to any standard. Really old film, from before the war, was shot on cameras that were either hand-cranked, or had a wind-up mechanism that did not produce a constant speed. In addition, even cameras manufactured after the war often had a "film saver" setting that let them run at very slow speeds. As a result, if you are trying to produce a video transfer that matches the original motion, you will often have to choose a playback speed other than 16, 18, or 24 fps. For instance, this backyard football game that I transferred from 1928 16mm film seemed to filmed at around 12 fps, which is what you will see if you play this clip:

1928 Backyard Kids Football in Oak Park, Illinois (https://www.youtube.com/watch?v=1YekFxBYKNM)

[papcom]

@johnmeyer, that's interesting. Some times ago when I mainly worked on Windows PC's I captured filmtransfers via a BMD Intensity Pro Card as 10bit YUV uncompressed data on HDU. Then I adjusted the speed of the AVi via the AVIFramerate converter and then I imported the resulting 18fps video into a 25fps progressive timeline on my editing software. The transfers remained sharp and the missing frames were inserted automatically, in order a correct 25fps videomaster result was output... unfortunately I found that the flow of the video was slightly stuttering... especially in horizontal pans.

I did not yet find a perfect way to get a really fluent standard PAL 25fps video out of a 18fps or a 16fps 8mm film. Either I have these slight stuttering coming from the frame doubling or I get some blending between the movements.

[johnmeyer]

@johnmeyer, that's interesting. Some times ago when I mainly worked on Windows PC's I captured filmtransfers via a BMD Intensity Pro Card as 10bit YUV uncompressed data on HDU. Then I adjusted the speed of the AVi via the AVIFramerate converter and then I imported the resulting 18fps video into a 25fps progressive timeline on my editing software. The transfers remained sharp and the missing frames were inserted automatically, in order a correct 25fps videomaster result was output... unfortunately I found that the flow of the video was slightly stuttering... especially in horizontal pans.

I did not yet find a perfect way to get a really fluent standard PAL 25fps video out of a 18fps or a 16fps 8mm film. Either I have these slight stuttering coming from the frame doubling or I get some blending between the movements.What you don't mention -- and which is more critical than anything else -- is what sort of transfer system you used. If you don't start with a truly frame accurate transfer, nothing else you have mentioned will matter: you can never get it to look right.

However, if you do have a frame accurate transfer, then the workflow I have already described will avoid every single problem you mentioned.

[papcom]

I have retried Your FPS script with a AVIfile of a Frame by Frame filmtransfer that runs with 16fps.

I put this 16fps avifile as the source and executed Your script, with the result that the 16fps file plays now with 25 fps ...which is of course too fast.

AVISource("C:\videodaten\intensitytest8mm_16fpsdatei.avi")
AssumeFPS(50,1)
#~ AssumeTFF() # or BFF, as required
#~ SeparateFields()
#~ SelectEvery(4, 0, 3)
#~ Weave()

Where is the misunderstanding? The end-result should be a 25fps Video playing the fimtransfer with 16fps.

[StainlessS]

Im not sure that I understand, but try this:

QTInput("C:\testfilm_.mov") .FlipHorizontal()
AssumeFPS(16.0) # or 18.0

ChangeFPS(50,1)
AssumeTFF() # or BFF, as required
SeparateFields()
SelectEvery(4, 0, 3)
Weave()

[papcom]

thank you @stainlesss , this helped.... and makes sense to me, because I mistyped assume and change. Great. (This is the answer to my second question in this thread.)

It is correct that it works also without the assumeFPS when the Input source already has the Speed of 16fps (18fps)?

[johnmeyer]

StainlessS has it right.

You need to spend some time reading the AVISynth help file so that you understand the difference between AssumeFPS and ChangeFPS. They do completely different things. You need them both for this job, but they need to be used in the right order.

Also, it sure would be nice if you read my earlier posts in this thread:

http://forum.doom9.org/showthread.php?p=1719802#post1719802

http://forum.doom9.org/showthread.php?p=1719815#post1719815

I provided the correct script (same as what StainlessS just posted) in the first post, and then described how to add the AssumeFPS() in the second post. You already had the answer ...

[papcom]

thank You @johnmeyer - You are right. I saw that You have already written this Detail (add assumeFPS) before. I appreciate Your help very much. Sometime it is not so simple... especially if mother language and forum language differ. I will try harder :-) Thanks again

[StainlessS]

It is correct that it works also without the assumeFPS when the Input source already has the Speed of 16fps (18fps)?

Yes, correct.

EDIT: And I did not notice (or pay attention to) John's AssumeFPS hint in his earlier post, either. I figured out what the problem might be
from your post #32 (which did not make much sense to me at first).

[johnmeyer]

thank You @johnmeyer - You are right. I saw that You have already written this Detail (add assumeFPS) before. I appreciate Your help very much. Sometime it is not so simple... especially if mother language and forum language differ. I will try harder :-) Thanks againI studied German in high school back in the 1960s and, like most Americans, I probably couldn't order breakfast in your language. So, I have great admiration that you can contribute to a forum in a different language than your native tongue.

[StainlessS]

couldn't order breakfast

'Frustucke', or something like that, (would not like to see you starve).
I have difficulty in English too, my first language is "Geordie".

EDIT: Looked it up, actually Frühstück.

[johnmeyer]

'Frustucke', or something like that, (would not like to see you starve).
I have difficulty in English too, my first language is "Geordie".Frühstück. Don't forget those umlauts!

I'm very sensitive to that because I founded and ran a desktop publishing software company back in the 1980s, and our software didn't initially include some of the Danish characters (e.g., Ø). I received a letter from someone in Denmark in which he removed all occurrences of the letter "g" and asked me how I like reading English with one letter missing.

[StainlessS]

Dont know how to get umlaut on the keyboard ( :confused: )
but I knew there was a couple in there and suspected the 'h' too.

The Danes in 80's were more likely to use GemDos (PC or Atari ST) because of support for weird foreign letters, Windows 95 (or was it 3.1) changed all that.
GemDos (AKA CPM 68K on Atari ST) was official from Digital Research. MSDOS was a rip-off of CPM (Z80 only, un-officially ripped for 8080 processor which executed a subset of Z80A instructions). Gates bought it for $50,000 and licensed it to IBM.
Digital Research (EDIT: Gary Kildall) should have brought in the lawyers over that one.

[johnmeyer]

Dont know how to get umlaut on the keyboard ( :confused: )
but I knew the was a couple in there and suspected the 'h' too.

The Danes in 80's were more likely to use GemDos (PC or Atari ST) because of support for weird foreign letters, Windows 95 (or was it 3.1) changed all that.
GemDos (AKA CPM 68K on Atari ST) was official from Digital Research. MSDOS was a rip-off of CPM (Z80 only, un-officially ripped for 8080 processor which executed a subset of Z80A instructions). Gates bought it for $50,000 and licensed it to IBM.
Digital Research should have brought in the lawyers over that one."Foreign" characters can be had by using the Alt key and the numeric keypad. Word has nifty shortcuts built in (e.g., Ctrl + : + U gives you Ü).

Your history is 100% correct.

I worked at Digital Research when GEM was created (the company I later founded used GEM). I knew Gary Kildall, and know all about how CP/M was copied by Seattle Computing, which then sold their version of CP/M (which they called QDOS = Quick and Dirty OS) to Gates for $50,000 just a few hours after IBM asked Bill if Microsoft could license a PC operating system because IBM had failed to get a license to CP/M from Dorothy Kildall, Gary's wife who handled all the business transactions.

Many years later, I met and had lunch with the IBM people who visited Digital Research (DRI) on that fateful day when IBM and DRI couldn't come to agreement on a license. The main problem was IBM's non-disclosure which ran on for over twenty pages (most non-disclosure forms are one page long). Gerry Davis (DRI's lawyer) got way too involved and spooked Dorothy into not signing that document, so they never even got to the licensing discussions.

When Gary died, everyone said how sad it was that he didn't end up a billionaire like Gates, but the truth is that Gary made plenty of money, and had more toys than anyone I've ever met ("the guy who dies with the most toys wins"). Also, in the book (and TV series) "They Made America," the person chosen as being most responsible for the personal computer revolution was not Jobs or Gates, but Kildall because it was he who invented the operating system as we know it today, most importantly the concept of device drivers.

Gary was a great guy, and you would have loved him. He lived to write code and build "cool stuff," as Jobs might have said.

[StainlessS]

Quite Fascinating. I dont expect that Gates had any real idea what he was doing at the time, just one of the luckiest flukes of all,
he just grabbed the great bear's tail and hung on for dear life.

[creaothceann]

Dont know how to get umlaute [...] :confused:
http://i.imgur.com/VUVbWAn.png

[StainlessS]

Thanx creaothceann.
I knew that (use it all of the time in SubRip) but could not be bothered, and typing at random with the alt key down did not seem at all attractive.

And, with a name like Meyer, I would expect John's German to be a little better than my un-schoole'd attempt.

EDIT: Just curious John, do you know if QDOS was a re-write OR (as I would have done) a disassembly of CPM's
Z80 into 8080 assembler followed by inserting 8080 patches to take the place of the Z80's extra instructions.
(The Z80A had [I think] 57 extra instructions which were not often used, and the 'A' version also had an alternate
register set, [avoid register store on stack in interrupts or exceptions]. Although the machine code for most instructions
was compatible, the assembly language for Z80 and 8080 was different).
I think QDOS was written/ripped by a student who had access to a mainframe (later Seattle Computing).

[johnmeyer]

Just curious John, do you know if QDOS was a re-write OR (as I would have done) a disassembly of CPM's Z80 into 8080 assembler followed by inserting 8080 patches to take the place of the Z80's extra instructions.

(The Z80A had [I think] 57 extra instructions which were not often used, and the 'A' version also had an alternate
register set, [avoid register store on stack in interrupts or exceptions]. Although the machine code for most instructions
was compatible, the assembly language for Z80 and 8080 was different).

I think QDOS was written/ripped by a student who had access to a mainframe (later Seattle Computing).I don't know the answer, but I can find out. Gary's right-hand man was Tom Rolander. I've known Tom for decades, and he is now in his late 60s, still flying, sailing, and writing lots of code. He loves programming. Tom is the keeper of Gary's flame and knows more about Gary's history that Gary himself did when he was alive. I'll ask him and let you know what I find out.

[StainlessS]

Thanx, I pondered that one a number of times, it is definitely what I would have done but then I'm not that fine and upstanding a person :)
I think the student had an 8080 m/c but no OS and that was the reason for the hack, not done as any kind of marketing exercise.
If you find out, do tell.

[johnmeyer]

I just sent Tom and email. I'll post back here when I get an answer. I am 99.9% certain he'll know the answer.

P.S. When I was describing Tom, I forgot to mention that he is also an amazing marathon runner. At age 67, he just completed another Big Sur Marathon. He is one of only two people to have run every single one of these races since it was first run in 1983. He has also, on multiple occasions, run the Boston Marathon and then, just a week later, the Big Sur Marathon. Here is a quick summary of his accomplishments:

Tom Rolander Bio (https://www.ee.washington.edu/people/alumni/profiles/tom_rolander.html)

[StainlessS]

Thats nothing, I've done hundreds of Marathons, (think its the peanuts I like best).

EDIT:
Oops, they call'em Snickers now:- https://www.google.co.uk/search?q=marathon+chocolate&biw=1280&bih=837&tbm=isch&imgil=ZhkIc8cjBMWsjM%253A%253B1X-cvsqXhOwGuM%253Bhttp%25253A%25252F%25252Fwww.dailymail.co.uk%25252Fnews%25252Farticle-565849%25252FFarewell-Snickers-Marathon-bars-make-comeback.html&source=iu&pf=m&fir=ZhkIc8cjBMWsjM%253A%252C1X-cvsqXhOwGuM%252C_&usg=__SUzi7Q0mlOv9x_FF8ZkwtAmZkBw%3D&ved=0CCoQyjc&ei=pdxHVaW3JZSdygTI54GYBA#imgrc=ZhkIc8cjBMWsjM%253A%3B1X-cvsqXhOwGuM%3Bhttp%253A%252F%252Fi.dailymail.co.uk%252Fi%252Fpix%252F2008%252F05_03%252FMaraSnicksDM_468x308.jpg%3Bhttp%253A%252F%252Fwww.dailymail.co.uk%252Fnews%252Farticle-565849%252FFarewell-Snickers-Marathon-bars-make-comeback.html%3B468%3B308

EDIT: Actually no, they got named back to Marathon again after 18 Years.
Just waiting for Opal Fruits to make a comeback, (daft name StarBurst).

EDIT: No, just a malicious rumour, is still Snickers.