妖精現実フェアリアル

2008-05-03 建国記念の日は2月18日でも良かった

Wikipediaによると、建国記念の日の元となった日付は西暦・紀元前660年2月11日だという。正確に言うと、これは「西暦」ではなく「グレゴリオ暦」のようだ。それに気が付いたのは、この日が新月だという記述から。アストロロギアは紀元前660年の月齢も出せるので、調べてみたら、

紀元前660年は−659年
天文学では紀元前1年を0年、紀元前2年を−1年…とするので1ずれる

日本時間
  ○ 満月 : -659年 2月 4日 16時25分31秒4
     下弦 : -659年 2月11日 21時50分00秒2
  ● 新月 : -659年 2月18日 16時50分11秒9

計算が合わず、2月11日は下弦になってしまう。新月は2月18日だ。

遠い過去や未来では、このようなずれはΔTと呼ばれる地球自転角の揺らぎに起因することが多い。人間の日付が地球の自転回数によっているのに対し、力学時は基準地点（例えば太陽系重心）における86400秒を1日とする。そのため例えば遠い過去や未来に、地球の自転周期が23時間や25時間になると、時刻や日付の観念が混乱する。 ΔTは推定してできるだけ補正するが、あまりに遠い過去や未来となると正確な補正は難しい。しかし−659年は位置天文学では遠い過去とは言えず、ΔTが7日もずれることはあり得ない。となると、1582年でユリウス暦にスイッチせずグレゴリオ暦のままさかのぼった、という可能性が浮かぶ。どうなるか考えてみよう。初期条件は、

グレゴリオ暦 1582年10月15日 ＝ ユリウス暦 1582年10月5日 # 差 G−J = d=10 [days]

グレゴリオ暦は回転が速いカレンダー、ユリウス暦は少しもたつくカレンダーで、両者の速度差は400年につき3日だ。差が変化する場所を詳しく見ると、

グレゴリオ暦       ユリウス暦
1500年3月11日  1500年3月 1日 # d=10
1500年3月10日  1500年2月29日 # ユリウス暦では2月29日あり d=10 ★
1500年3月 9日  1500年2月28日 # d=10
1500年3月 8日  1500年2月27日 # d=10
1500年3月 7日  1500年2月26日 # d=10
1500年3月 6日  1500年2月25日 # d=10
1500年3月 5日  1500年2月24日 # d=10
1500年3月 4日  1500年2月23日 # d=10
1500年3月 3日  1500年2月22日 # d=10
1500年3月 2日  1500年2月21日 # d=10
1500年3月 1日  1500年2月20日 # d=10
1500年2月28日  1500年2月19日 # グレゴリオ暦では2月29日なしd=9 ★★
1500年2月27日  1500年2月18日 # d=9

★の時点でユリウス暦は2月29日を踏むが、その数日前、グレゴリオ暦は2月29日を飛ばしている。つまり過去方向にさかのぼっていくと、★★の時点で差が10日から9日に縮まる。

注意: これらはあくまで計算上の話で、現実の歴史では1582年の改暦前にグレゴリオ暦を使っていた地域は存在しないから、歴史上は存在しない日付である。一方、1582年にすぐにグレゴリオ暦に切り替えなかった地域は存在するので、 1582年以降は両方の日付が現実的にも存在した。さらに、ユリウス暦の方はユリウス暦制定前にまでさかのぼって用いられる。何となく不公平なようだが、少なくとも天文学ではそうしている。

同様に、−600年までさかのぼってみる。差はだんだん縮まって、300年ごろには両者は一致し、さらに過去へ戻れば今度は逆にユリウス暦の日付の方が前方（未来の日付）になる。例えば、グレゴリオ暦 100年2月28日はユリウス暦 100年3月1日だ。グレゴリオ暦は回転の速いカレンダーで、通常、ユリウス暦より前を走っている日付なのだが、もし「逆走レース」をすると巻き戻りも速くてユリウス暦を「バックで追い抜いて」しまう。

「バックで追い抜く」とは、 紀元前数世紀ごろの同じ日付をグレゴリオ暦で言うと、ユリウス暦で言った場合より数日前になるということだ。（カレンダーが違うので同じ日が別の日付になるというだけで、実際には同じ日。）

差の変化の概要は下記のとおり。 400で割り切れる年はどちらもうるう年なので、そこでは差の増減はないが、それ以外の100で割り切れる年は、グレゴリオ暦では平年、ユリウス暦ではうるう年となって、ユリウス暦だけが2月29日を持つ。「グレゴリオ暦の2月28日はユリウス暦の何月何日か」という視点で見ると、過去へ戻れば戻るほどこの日付は遅くなる。

グレゴリオ暦 1300年2月28日 ＝ ユリウス暦 1300年2月21日 # d=7
グレゴリオ暦 1100年2月28日 ＝ ユリウス暦 1100年2月22日 # d=6
グレゴリオ暦 1000年2月28日 ＝ ユリウス暦 1000年2月23日 # d=5
グレゴリオ暦 900年2月28日 ＝ ユリウス暦 900年2月24日 # d=4
グレゴリオ暦 700年2月28日 ＝ ユリウス暦 700年2月25日 # d=3
グレゴリオ暦 600年2月28日 ＝ ユリウス暦 600年2月26日 # d=2
グレゴリオ暦 500年2月28日 ＝ ユリウス暦 500年2月27日 # d=1
グレゴリオ暦 300年2月28日 ＝ ユリウス暦 300年2月28日 # d=0
グレゴリオ暦 200年2月28日 ＝ ユリウス暦 200年2月29日 # d=−1
グレゴリオ暦 100年2月28日 ＝ ユリウス暦 100年3月1日 # d=−2
グレゴリオ暦 −100年2月28日 ＝ ユリウス暦 −100年3月2日 # d=−3
グレゴリオ暦 −200年2月28日 ＝ ユリウス暦 −200年3月3日 # d=−4
グレゴリオ暦 −300年2月28日 ＝ ユリウス暦 −300年3月4日 # d=−5
グレゴリオ暦 −500年2月28日 ＝ ユリウス暦 −500年3月5日 # d=−6
グレゴリオ暦 −600年2月28日 ＝ ユリウス暦 −600年3月6日 # d=−7

西暦−659年においては、グレゴリオ暦の日付は、ユリウス暦の日付より7日若い。
グレゴリオ暦 −659年 2月11日 = ユリウス暦 −659年 2月18日

どうやら建国記念の日の「2月11日」は通常の西暦ではなく、グレゴリオ暦をさかのぼって適用した日付だったようだ。通常の西暦では1582年より前はユリウス暦で言う。その意味では、建国記念の日は2月18日でも良かったわけだ。建国記念の日を計算したとき、過去の日付もさかのぼってグレゴリオ暦で考えたのだろう。確かにその方が、考え方としてはスッキリしている。暦学・天文学では普通グレゴリオ暦を1582年より前にさかのぼっては使わないし、歴史学では日付の混乱の原因になるので絶対そんなことはしないだろうが、理論上は単なる表示の問題で、そうしてはいけない理由は何もない。間違っている・いないといった問題ではないし、神話時代の日付（物語の設定）をあまり現実的に検討しても仕方ないとも言える。西暦もキリストが生まれた年を紀元にした…はずだったのだが、実際の生誕年と数年ずれているそうだ。

このメモは「ユリウス暦とグレゴリオ暦の違い」が思いがけないところに影響している、ということが興味の中心で、「建国記念の日」やその日付の計算の価値を是認するものでも否定するものでもない。「建国記念の日は本当は2月18日が正しい」とか、祝日に意味があるとかないとかいった、政治的主張を含んでいるわけではなく、あくまで暦学的な興味だ。

「バックで追い抜いた」グレゴリオ暦だが、さらに過去に進めば差が一周遅れに達し、またユリウス暦と一致する場所が出る。逆に、遠い未来においても、グレゴリオ暦とユリウス暦の差が一周に達し、再び一致するときがあるはずだ。

2008-05-01 可逆映像圧縮のLagarith

実用上は、Huffyuvで完全に満足している。一時、CorePNGに浮気したが、軽さでHuffyuvに戻った。 CorePNGのほうがHuffyuvより大きくなる場合があることを体験して、熱が冷めた。大半の例ではCorePNGの方がかなり縮むので、保存するならサイズ的にメリットがあるが、すぐ消してしまう中間ファイルは多少大きくても軽い方がいい。

Lagarithは、Huffyuvが進化したようなコーデックで、Huffyuvより少しだけ重いが、 CorePNGと比べたらかなり軽い。圧縮率も素晴らしい。特に前のフレームと同じ場合にNullフレームにするモードがいい。実写では前のフレームとまったく同じなどということはめったにないだろうが、実写でないものでは6フレームくらい止まっていることも珍しくない。それをいちいち個別に圧縮せず0バイト（ヘッダのみ）で済ますのは実にいい。

というわけで、いろいろ試してみたのだが、無圧縮AVIに戻して比較したら、 Huffyuvの解凍とLagarithの解凍でハッシュが合わない。とりあえず1フレームずつ、DIBで取り出して32ビットのチェックサムをとってみたら、全フレーム一致した。つまり（43億分の1の偶発的衝突が起きていない限り）画像データに差はない。しかし同じVDで同じ無圧縮RGB形式で書き出しているのに何で差ができるのだろう。バイナリエディタで調べてみろと言っても、GBオーダーのファイルのコンペアとなると、おいそれとはいかない。とにかく調べてみたら、HuffyuvはdwQualityが0なのに対して、Lagarithは10進数の10000に設定されていた。何だそんなことか…。というわけで、何の影響もない場所だった。念のために全バイト比較したが、ほかは全部一致していた。

多くの場合、動画は入出力ともいわゆるYUV系（YCbCrなど）になるけれど、中間でレタッチなどの加工をする場合、RGBを経由することも珍しくない。（AviUtlは確かデフォルトはYUV系で、コーデックごとの設定で変更だったと思う。）レタッチなどせず、そのまま2パスで最終結果に流し込むだけの中間ファイルならRGBにする必要はない。ビット深度が一致していてさえ、丸め誤差が出るし（といっても人間の目では分からないだろうが）、変換が入れば速度的にも遅くなるからだ。しかし何らかの理由でRGBに行く必要があるなら、なるべく速くRGBに入って最終過程の直前までRGBにいた方がいい。不必要にYUV系との相互変換を繰り返すのは余計な変換誤差の原因になる。 LagarithもHuffyuv同様、RGBはRGBのまま保持できるので、そのような目的でも問題なく使用できると思われる。

以前はタイプセットをするとき何でもかんでも（生データがDivXやXvidでも）いったんHuffyuvに展開する習慣だった。 Bフレームを逆に行くときなどシークが引っかかるのがいやだったからだ。今では、PCが速くなったのでMPEG-4 Part-2ビデオをそのまま使っても、まったくストレスがなくなり、むしろHuffyuvに展開する方が（たぶん帯域的な問題で）重く感じるようになった。目的が同じでも、ハードやソフトの変化で、最適解は変わりうる。 Huffyuvは枯れていていいけれど、速度的にわずかに遅いだけで圧縮率が有意に高いとなると、 Lagarithは、HDの転送速度などによっては結果的にかえって軽くなる場合もあるのではないか…。

2008-04-30 WavPack 4.5 beta available, also Winamp plugin 2.5 beta

2008-04-30 興味ない人にはどうでもいい豆知識なのだが、藤原拓海はR1版では「Tak」と呼ばれる。というわけで、「イニシャルDをTAKで圧縮！」とおちゃらけてみましたｗ　ダウンヒル（デコード）の速度なら負けないぜ！とか日光サル軍団（APE）とバトルしたりするのでしょうか。

ロスレスオーディオの拡張子「TAK」

Notepad++の構文強調を試しにユーザー定義してみた。正規表現が使えないのでEmEditorより簡易的だが、そのぶん軽く、支援目的には十分役立つかも。とはいえ、十分とは言えない。テストなのでもっといいやり方があるのかも。

EmEditorの場合。ASSの全コマンドが強調表示されるが、複雑なカラオケ行が続くところはスクロールが激重。決して悪くないがオープンソースでないうえ文字コードも厳密でない。