03:04 gorry5: 原理の話。MZの場合、0を示すビットを「100単位時間のH→100単位時間のL」、１を示すビットを「200単位時間のH→200単位時間のL」のような形で記録する

03:06 gorry5: '1011'のようなビットを書く場合、「200H,200L,100H,100L,200H,200L,200H,200L」のような形になる

03:08 gorry5: 一方、これを読み出すときは「Hが見つかってから150単位時間後がHかLか」のような方法で判定している。MZのROMでも、オリジナルのtaperead.exeでもそう

03:11 gorry5: しかしこれに歪みや揺らぎが発生すると、読み出した結果が「200H,200L,150H,100L,150H,200L,200H,200L」のようになってしまうことがある

03:14 gorry5: 150単位時間後の状態を読むのに"150H"があっちゃまずい。読み出し結果がH/Lどっちになるか運次第

03:18 gorry5: で、対策。揺れても半周期くらいで安定するなら、１周期読んでからその総時間で判定してはどうか

03:20 gorry5: 200H+200L=400, 150H+100L=250, 150H+200L=350, 200H+200L=400だから、300くらいを1/0の境目にしておけば結果として正しいことになる

03:35 gorry5: 実例、sb_fromtape.wavがテープから実際に読んだデータ。比べると興味深い URL:gorry.haun.org

03:45 gorry5: taperead_g.cppの改変具合はまさにhack。真似しちゃだめよ :D