つくづく、コンピューターは日本人に使いにくいなぁと思った話。TranscendのMP3プレーヤー、M330っていうのを買ってみた。iTunesに入っているアルバムのいくつかをAmadeus Proというサウンド・エディターの変換機能を使ってmp3にしてこのM330にコピーしたところ、まぁ何の問題もなく再生され、再生中のファイル名も表示された、の・だ・が・・・・ 曲のタイトル、アーティスト名、アルバム名が文字化け表示!
ははぁーん、これはID3タグがちゃんとしてないんだな、と思い、ID3タグ編集用のTagr.appってフリーソフトをダウンロードしてきっちりと入れなおしてみた。でも治らない。
mp3ファイルはもともと音楽をMPEG1 Layer 3という形式でエンコードしたサウンド・ファイルだったが、MP3プレーヤーのソフトやハードがどんどん登場して、ファイル交換時に曲名やアーティスト名も一緒に受け渡せるようにフォーマット拡張されたのが"ID3タグ"だ。コンピューターの世界で多国語対応が標準的になったのはWindows 2000、Mac OS Xになってからである。ID3タグが出た段階はまだWindows 98、Mac OS 8の時代、当然日本語のことなんて考えられていない。また、当時のパソコンの日本語コードはShiftJISだ。日本語化といえばShiftJISが採用されるのが自然の流れだった。ちなみにインターネットで使用される日本語コードはいわゆる7bit JIS=ISO 2022JPだった時のことだ。
OSがネイティブに多国語されるのはその数年後、そしてそこで採用されたのはUnicodeである。UnicodeにはUTF-8とUTF-16があるのだが、ID3タグの多国語対応時に採用されたのはまずUTF16で、最新版でようやくUTF8がにも対応した。(ちなみにUTF-32もある。)
しかし、同じ文字を表すのになぜにこうも異なったコードが乱立してしまったんだろう。コンピューターの処理能力とともに歩んで来た歴史の積み重ねというのは重々承知している。だが、英語圏ではこんなにも使い分けやプログラム実装に悩んだりする必要がないことを考えると、日本人はそれだけで重たいハンディを背負っている。
JIS、ShiftJIS、EUCの使い分けがUnicodeの登場で簡単になるのかと思いきや、またもやUTF-8とUTF-16で悩まされるのか。複雑化する一方だ。普段、ユーザーとしてパソコンを使う分にはそれほど気にすることはないにしろ、文字化けなどに遭遇したとき、突然にこのあたりの知識を要求されるのがキツい。
ASCIIを使っている連中は文字化けという現象に無頓着だ。したがって、ID3編集ソフトを作った人も「文字コードの変換」なんて機能は実装してない。Tagr.appがまさにそうだ。OSがサポートしてる文字コードをファイルに書きこめばいいだけなんだから。
で、先のMP3プレーヤーでの文字化けの問題、ID3タグにUTF-8で日本語が書かれていたことで発生していた。この問題を解決できるのは日本人が作ったソフトしかないのはあたり前で、そういうソフトはMac用には見つからず、いろいろ試してようやく"Super TagEditor"というWindows用にたどり着いた。動作がいまいちなんだけど、なんとか無事に文字化けは解消された。
今回の件で、mp3のID3タグのことについて短期集中で勉強した。だが、iTunesとiPodを使っている限りこんなことは知らなくていいことだし、問題は特殊なことをやろうとしない限り顕在化しない。知識はあっても、それが金にならないという典型的なパターンだから悲しい。最終的にブログでぼやくわけだが、これすら時間の浪費でしかない。
2/24/2011
2/16/2011
iPhoto 9.1.1 (iLife '11) でプリントができないなら Themeを消して再インストール
またまたiPhoto 9.1.1でトラブルに遭遇した。最近はめっきり写真をプリントすることがなくなったのでいつからこんなトラブルがあったのかわからないんだけど、写真を選んでファイル・メニューから「プリント」を選ぶとアラートが出て
「利用てきるテーマが見つかりません。: テーマが見つかりませんでした。少なくとも1つのテーマがインストールされるまでは、この機能は使用できません。」
と言われる。こ、これはAppleのHuman Interface Guidelinesで「ダメ」とされてる「A poorly written alert messages」にちょっとばかし説明を加えた程度のひどいアラートだ。テーマをどうしたらインストールできるのかがわからない上、「OK」を押してプリントをやめるしかない。
そもそもテーマってなんだよ。ってことでiPhotoのヘルプを見ようとしたら
「HVURLHandlerErrorDomain エラー 1002」
これまた完全な「A poorly written alert message」が堂々と登場。結局頼れるのはGoogle様ということで解決法を探った。
まずはプリントが出来ない件。
で解決。このヘルプの問題は日本だけで発生する問題らしい。Appleの開発とQAはほぼCupertinoで行われているので、アメリカ人から文句の来てないようなバグは、知らないので対処されないまま放置されてしまうみたいだ。
「利用てきるテーマが見つかりません。: テーマが見つかりませんでした。少なくとも1つのテーマがインストールされるまでは、この機能は使用できません。」
と言われる。こ、これはAppleのHuman Interface Guidelinesで「ダメ」とされてる「A poorly written alert messages」にちょっとばかし説明を加えた程度のひどいアラートだ。テーマをどうしたらインストールできるのかがわからない上、「OK」を押してプリントをやめるしかない。
そもそもテーマってなんだよ。ってことでiPhotoのヘルプを見ようとしたら
「HVURLHandlerErrorDomain エラー 1002」
これまた完全な「A poorly written alert message」が堂々と登場。結局頼れるのはGoogle様ということで解決法を探った。
まずはプリントが出来ない件。
- "/Library/Application Support/iPhoto/Theme" を削除
- ”/Application” からiPhotoを削除
- iLife '11のディスクからiPhotoをインストール
- iPhotoを最新版にアップグレード
次、ヘルプが出ない件。
- "~/Library/Preferences/com.apple.help.plist" を削除
- 一旦ログアウト
- 再度ログイン
で解決。このヘルプの問題は日本だけで発生する問題らしい。Appleの開発とQAはほぼCupertinoで行われているので、アメリカ人から文句の来てないようなバグは、知らないので対処されないまま放置されてしまうみたいだ。
2/02/2011
「昔日の客」とメディアの価値
元大田区役所のあったあたり、大森日赤前のバス停のすぐ目の前に「山王書房」という古本屋がかつてあった。子供の頃から小説など全く読むことのない私には縁のない店だったが、となりの叔父などはよく行ってはそこの主人の長話につかまってたらしい。叔父の家にはいまでもそのお宅から年賀状が届くという。私の父も入二の教師をやっているころに寄ったことがあると言っていた。
その山王書房の主人によるエッセイ集がこの「昔日の客」だ。著者は残念なことに本書の初版が出版される前に60歳にも満たない生涯を終えている。昭和53年に出版されたこの本はしばらく絶版状態だったが、昨年(平成22年)に若干の手直しがされた上で復刻した。たかが大森の古本屋の主人が書いた本なれどこの本を求める人はそこそこあったようで、手元のものはすでに第二版となっていた。
昔の馬込の様子などが綴られているというのが本書を手にした動機で、私自身は特に文学に興味があるわけではない。なので、本書に登場する作家については何ひとつ知識がないままに読んだ。文章も読みやすく、この古本屋の主人の変人ぶりと書籍への愛情、作家への尊敬がにじみ出ていた。作家と読者をつなぐパイプ役として、双方から愛されていた様子も伝わってきた。
私が子供の頃は、うちのそばにも「貸本」をやっている馬込書房という店があった。バス通りに市場があって、その日の夕飯の買い物はその日にしていた時代だ。世の中はこのあと加速して変化して豊かになっていくのだが、当時、本は「貸本」で読むほどに庶民にとって高額なメディアだったのか、と改めて思う。当時子供で自分でお金を出して本を買うことはなかったので、実感としてはよくわからない。でもそうだったに違いない。「古本」の商売もそんな時代だったからこそ成り立っており、どれだけ良い本を揃えることができるかは、古本屋の主人の目利きにかかっていた。
「昔日の客」を読んで驚くのは、大森駅からさらにバスに乗らないと来られないような場所にある古本屋に、吉祥寺やら藤沢やら遠方から客がやってくること。本は高かったばかりでなく貴重で、体力使って探しまわらないと手に入らないようなものだった。そんな事情が、古本の価値を高め、さらに古本屋の力量の価値も上げていたということだ。
「昔日の客」は、今日で言えばブログに書かれているような内容だ。おおよそ散文なんてそんなもんだ。現代なら書いた時点ですぐに公開して、推敲を重ねた結果を反映させるのもリアルタイムにできる上、書いた内容についても一方通行でなく、読み手からのレスポンスもすぐに受け取れる。環境はコンテンツを創る側にとっても受ける側にとっても劇的に便利で安くなった。Googleで検索すれば次の瞬間には欲しかった物が手元に入る。「本」であってもアマゾンからたいていのものが翌日に届くし、希少本さえ体力を使わずに探し出すことができる。便利さと引き換えに「古本屋」という商売はリサイクルとしての価値しかなくなってしまった。品揃えとか目利きとかの価値もほぼ壊滅状態だ。
かつて「本」に書かれているコンテンツを得るためには、情報を持っている人と接し、実際にからだを動かして移動し、何件も本屋を回らなければならなかった。コンテンツの価値が変わらないとすれば、そのコンテンツを収録している本というメディアの価格以外に様々なコストを払わなければならなかった。インターネットによってメディア以外のコストはほとんどゼロになり、動く金の量が激減した。そして、様々な商売が消えていった。今や「本」というメディア自体のコストすらなくなろうとしている。
もはや、コンテンツについては作者とオーディエンスが直接向き合う時代になった。動く金の量が極端に減ってしまった。出版不況と言われているが、それは決して「活字離れ」なんてことが原因ではなく、メディア流通の価値がどんどん下がってしまった結果であり、CDが売れなくなったのとほぼ同じ理屈があてはまる。文学も音楽もコピーされなければ伝わらない。コピーがしにくければ人々はお金を出すが、自分で簡単にコピーできるものにお金は払わない。コピーさせないような技術は結局海賊版をはびこらせる。メディアでお金が取れない時代にコンテンツの作者は伝統的なビジネス・モデルそのものを考えなおさなければ生き残れない。
「昔日の客」を読みながら、出版業というのが本というメディアのおかげで潤うことができたのは、人類の歴史でほんの一瞬だったのかな、と思った。
その山王書房の主人によるエッセイ集がこの「昔日の客」だ。著者は残念なことに本書の初版が出版される前に60歳にも満たない生涯を終えている。昭和53年に出版されたこの本はしばらく絶版状態だったが、昨年(平成22年)に若干の手直しがされた上で復刻した。たかが大森の古本屋の主人が書いた本なれどこの本を求める人はそこそこあったようで、手元のものはすでに第二版となっていた。

私が子供の頃は、うちのそばにも「貸本」をやっている馬込書房という店があった。バス通りに市場があって、その日の夕飯の買い物はその日にしていた時代だ。世の中はこのあと加速して変化して豊かになっていくのだが、当時、本は「貸本」で読むほどに庶民にとって高額なメディアだったのか、と改めて思う。当時子供で自分でお金を出して本を買うことはなかったので、実感としてはよくわからない。でもそうだったに違いない。「古本」の商売もそんな時代だったからこそ成り立っており、どれだけ良い本を揃えることができるかは、古本屋の主人の目利きにかかっていた。
「昔日の客」を読んで驚くのは、大森駅からさらにバスに乗らないと来られないような場所にある古本屋に、吉祥寺やら藤沢やら遠方から客がやってくること。本は高かったばかりでなく貴重で、体力使って探しまわらないと手に入らないようなものだった。そんな事情が、古本の価値を高め、さらに古本屋の力量の価値も上げていたということだ。
「昔日の客」は、今日で言えばブログに書かれているような内容だ。おおよそ散文なんてそんなもんだ。現代なら書いた時点ですぐに公開して、推敲を重ねた結果を反映させるのもリアルタイムにできる上、書いた内容についても一方通行でなく、読み手からのレスポンスもすぐに受け取れる。環境はコンテンツを創る側にとっても受ける側にとっても劇的に便利で安くなった。Googleで検索すれば次の瞬間には欲しかった物が手元に入る。「本」であってもアマゾンからたいていのものが翌日に届くし、希少本さえ体力を使わずに探し出すことができる。便利さと引き換えに「古本屋」という商売はリサイクルとしての価値しかなくなってしまった。品揃えとか目利きとかの価値もほぼ壊滅状態だ。
かつて「本」に書かれているコンテンツを得るためには、情報を持っている人と接し、実際にからだを動かして移動し、何件も本屋を回らなければならなかった。コンテンツの価値が変わらないとすれば、そのコンテンツを収録している本というメディアの価格以外に様々なコストを払わなければならなかった。インターネットによってメディア以外のコストはほとんどゼロになり、動く金の量が激減した。そして、様々な商売が消えていった。今や「本」というメディア自体のコストすらなくなろうとしている。
もはや、コンテンツについては作者とオーディエンスが直接向き合う時代になった。動く金の量が極端に減ってしまった。出版不況と言われているが、それは決して「活字離れ」なんてことが原因ではなく、メディア流通の価値がどんどん下がってしまった結果であり、CDが売れなくなったのとほぼ同じ理屈があてはまる。文学も音楽もコピーされなければ伝わらない。コピーがしにくければ人々はお金を出すが、自分で簡単にコピーできるものにお金は払わない。コピーさせないような技術は結局海賊版をはびこらせる。メディアでお金が取れない時代にコンテンツの作者は伝統的なビジネス・モデルそのものを考えなおさなければ生き残れない。
「昔日の客」を読みながら、出版業というのが本というメディアのおかげで潤うことができたのは、人類の歴史でほんの一瞬だったのかな、と思った。
12/17/2010
Macの計算機.app 換算レートがアップデートできないなら英語モードで起動しろ
Macにはソフトウェア電卓っていうのが初代からついている。「コンピューターで仕事してるのに、計算するときに電卓を使ってその値をコンピューターに入力するっておかしいだろ。電卓よりコンピューターの方が高度な計算ができるのに!」って発想だろうけど、以前はデスク・アクセサリー(DA)として、どんなソフトを利用している時でもアップル・メニューから起動して計算結果をコピー・アンド・ペーストできた。Mac OS Xでは単独のアプリとして多機能関数電卓が実装されていて、私の場合、今でもちょっとしたことによく使うためDockに入っている。特にバージョンアップとかも期待してないけど、ないとちょっと不便だ。単位の換算とか為替の計算などにもちょくちょく使う。
ところが、今年の夏頃からこの単純なアプリケーションに問題が生じた。換算レートをアップデートしてくれないのである。それまでは、計算機を立ち上げるごとに常に最新のレート情報を持ってきてくれてたので、「今アメリカのAmazonでこれ買うと何円だな、ふむふむ」なんてことは10秒かからなかった。まぁ、ネット時代、こういうことはたまに起きるよね、くらいに思っていたらいつまでたっても対処されない。こんなことでは世界中のユーザーが困っておろうに、と思って対処の仕方を検索したが、特に問題になっている様子がなかった。
で、昨日、久々に「これ未だに問題にされていないのかな」とググってみたところ、同じように困っている人がいましたよ。困ってる人同士のやりとりのなかで解決策がしめされたました。「計算機.appを英語モードで立ち上げるとちゃんとレートをアップデートする」んだって。英語モードで立ち上げるには、Language Switcherなんてソフトもあったりする。ははぁ、どおりでAppleがちっとも対処しないわけだ。開発者はこんな問題があることをわかっていないか、ぜーんぜん低いプライオリティにしているかのどちらかなんだ。
しかし、計算機なんていう超クラシックな超スタンダードな超単純なソフトが、表示言語が違うだけでちゃんと動作しないこと自体が驚きだ。なんでそんなことが起こるのか、困ってる人同士のやりとりでは明らかになっていない。
計算機.appが為替レートの情報を取ってくる先はfinance.yahoo.comらしい。とすると、Appleが知らないうちにここでのAPIに変更があったか、あるいはフィードされるxmlが変わって計算機.appが認識できないかのどちらかと思われる。そうだとすれば、日本語モードになっているときと英語モードの時とで、やり取りされるコマンドとレスポンスが異なっていたということになるんだが、具体的に見てみるにはパケット・アナライザーをかまさなくてはいけない。そういうデータ取りをできないわけではないが、それをするのはAppleの仕事だ。
2011年1月13日追記:
Apple製のアプリは日本語版も本社で開発してるから、不具合があったらユーザーからバグレポートを上げないと対処に動かないらしい。計算機.appの換算レートがアップデートしない件、英語モードでは再現しないので、開発側が気がついていないのかもしれない。
2011年11月12日追記:
Lionの計算機.appではちゃんと直っていた。
ところが、今年の夏頃からこの単純なアプリケーションに問題が生じた。換算レートをアップデートしてくれないのである。それまでは、計算機を立ち上げるごとに常に最新のレート情報を持ってきてくれてたので、「今アメリカのAmazonでこれ買うと何円だな、ふむふむ」なんてことは10秒かからなかった。まぁ、ネット時代、こういうことはたまに起きるよね、くらいに思っていたらいつまでたっても対処されない。こんなことでは世界中のユーザーが困っておろうに、と思って対処の仕方を検索したが、特に問題になっている様子がなかった。
で、昨日、久々に「これ未だに問題にされていないのかな」とググってみたところ、同じように困っている人がいましたよ。困ってる人同士のやりとりのなかで解決策がしめされたました。「計算機.appを英語モードで立ち上げるとちゃんとレートをアップデートする」んだって。英語モードで立ち上げるには、Language Switcherなんてソフトもあったりする。ははぁ、どおりでAppleがちっとも対処しないわけだ。開発者はこんな問題があることをわかっていないか、ぜーんぜん低いプライオリティにしているかのどちらかなんだ。
しかし、計算機なんていう超クラシックな超スタンダードな超単純なソフトが、表示言語が違うだけでちゃんと動作しないこと自体が驚きだ。なんでそんなことが起こるのか、困ってる人同士のやりとりでは明らかになっていない。
計算機.appが為替レートの情報を取ってくる先はfinance.yahoo.comらしい。とすると、Appleが知らないうちにここでのAPIに変更があったか、あるいはフィードされるxmlが変わって計算機.appが認識できないかのどちらかと思われる。そうだとすれば、日本語モードになっているときと英語モードの時とで、やり取りされるコマンドとレスポンスが異なっていたということになるんだが、具体的に見てみるにはパケット・アナライザーをかまさなくてはいけない。そういうデータ取りをできないわけではないが、それをするのはAppleの仕事だ。
2011年1月13日追記:
Apple製のアプリは日本語版も本社で開発してるから、不具合があったらユーザーからバグレポートを上げないと対処に動かないらしい。計算機.appの換算レートがアップデートしない件、英語モードでは再現しないので、開発側が気がついていないのかもしれない。
2011年11月12日追記:
Lionの計算機.appではちゃんと直っていた。
11/26/2010
メールに巨大ファイルを添付してはいけない理由
義理の父のところに、写真を十数枚添付した同じメールが複数届いて、なにやらパソコンがおかしくなったとの電話があった。詳しく聞いてみると、セミナー仲間の誰かが複数の方にこの大容量メールを送ったため、携帯でメールを受けている人を中心に騒ぎになったらしい。
義父のメールボックスは私のところのサーバーにあるので、ログをチェックしたところ、なるほど同じ方から同じサイズのメールが連続して届いていた。義父に解説を書いたのだけど、せっかくの長文を書いたので、ブログにも転載しておくことにした。:
義父のメールボックスは私のところのサーバーにあるので、ログをチェックしたところ、なるほど同じ方から同じサイズのメールが連続して届いていた。義父に解説を書いたのだけど、せっかくの長文を書いたので、ブログにも転載しておくことにした。:
気軽になんでも送れるように思われるメールですが、実は様々なところで容量の制限がされています。というのも、メールは手元から発信側のサーバーにコピーされ、受信側のサーバーにコピーされ、最終的に受け手のパソコンにコピーされて届くものなので、それぞれの場所でディスクの容量を消費してしまうものだからです。
たいてい、送信側のサーバーにも容量の上限があり、受信側サーバーのメールボックスにも容量の上限があります。受信側のメールボックスは複数の人からのメールを受け取るので、いつまでもパソコンで受け取らないと最後にはどんな小さなサイズのメールも受け取ることができなくなります。そんなときには、メールは送信者に戻されることになります。当然送信者側のメールボックスにたくさんのメールが戻ってくると容量オーバーになるので、連鎖的にメールシステムがダメージを受けることになります。
これが「メールに大きなサイズのファイルを添付してはいけない」理由です。
今回、受信側で容量オーバーは起きてませんでした。(これは、こちらのサーバーに容量の上限を設定していないからです。たとえば、JCOMの場合メールボックス上限は20MB程度です。)
参考: http://www.jcom.co.jp/services/net/services/ata/summary.html
今回のケースでは、送り手側が送信時に何らかのエラーがあったため、何度も送りなおしをしてしまったということが考えられます。
まぁ通常メールで送る添付ファイルは1MB以下が理想で、どうしても大きくなってしまう場合でも5MB以下に抑えておかないとトラブルのもとです。とはいいつつ、近年写真のサイズはかなり大きいので、その場合はファイル共有サービスや写真共有サービスを利用するのが好ましいでしょう。
以上、ご友人に転送して解説しておいていだだくとよろしいかと思います。
11/12/2010
iPhoto 9.1 (iLife '11) が起動しないならDivXを消せ! Remove DivX for iPhoto 9.1 to launch!
Snow Leopard に iLife '11を導入したところ、iPhotoは緊急のアップグレードがあってiPhoto 9.1となった。ドックからiPhotoをクリックするとアイコンがしばらく飛び跳ね、やがて止まった。しかし起動しない。しかもiPhotoがCPUを100%使って応答しない状態。どうにもならないので、iPhotoを9.0にダウングレードしたらちゃんと起動した。
しかし、11月12日にOS Xが10.6.5にアップすると、今度は「iPhotoをアップグレードしろ」とメッセージを出してiPhotoが起動しない。しかたなく再び9.1にアップ。当然、前と同じ現象で起動しない。
とにかくネットで情報収集したところ、どうやらDivXの古いドライバーが干渉するとのこと。2004年製のDivX Pro5.component、DivX MP3 Encoder.componentというふたつのQuickTimeコンポーネントを、/Library/QuickTime (/ライブラリ/QuickTime) から出したところすんなり起動した。
これは難しい。誰もiPhotoとDivXが関係するとは思いもよらない。見つけた人はえらい。
海外でもきっと困ってる人がいるので、同じ内容を英語でも以下に書いておいた。
I installed iLife '11 on Snow Leopard and applied immediate update of iPhoto to 9.1. I clicked the iPhoto icon at the dock, the icon kept bouncing and then stopped. But iPhoto didn't show up, taking 100% of CPU load. The application was not responding at all. After a couple of trials, I downgraded it to 9.0 and it got working fine.
However, OS X was updated to 10.6.5 on Nov. 12th, I got an alert saying "iPhoto needs to be updated" and never launched up. Updated to 9.1 and of course, the symptom was restored again.
Anyway, I researched around the Internet and found that the old DivX driver seemed to be interfering. I removed two QuickTime components: DivX Pro5.component and DivX MP3 Encoder.component, both of which were created in "2004", from /Library/QuickTime. Finally, it worked fine.
What a difficult matter was this! Who can imagine the connection between iPhoto and DivX! What a clever one discovering this! I owe him/her.
しかし、11月12日にOS Xが10.6.5にアップすると、今度は「iPhotoをアップグレードしろ」とメッセージを出してiPhotoが起動しない。しかたなく再び9.1にアップ。当然、前と同じ現象で起動しない。
とにかくネットで情報収集したところ、どうやらDivXの古いドライバーが干渉するとのこと。2004年製のDivX Pro5.component、DivX MP3 Encoder.componentというふたつのQuickTimeコンポーネントを、/Library/QuickTime (/ライブラリ/QuickTime) から出したところすんなり起動した。
これは難しい。誰もiPhotoとDivXが関係するとは思いもよらない。見つけた人はえらい。
海外でもきっと困ってる人がいるので、同じ内容を英語でも以下に書いておいた。
I installed iLife '11 on Snow Leopard and applied immediate update of iPhoto to 9.1. I clicked the iPhoto icon at the dock, the icon kept bouncing and then stopped. But iPhoto didn't show up, taking 100% of CPU load. The application was not responding at all. After a couple of trials, I downgraded it to 9.0 and it got working fine.
However, OS X was updated to 10.6.5 on Nov. 12th, I got an alert saying "iPhoto needs to be updated" and never launched up. Updated to 9.1 and of course, the symptom was restored again.
Anyway, I researched around the Internet and found that the old DivX driver seemed to be interfering. I removed two QuickTime components: DivX Pro5.component and DivX MP3 Encoder.component, both of which were created in "2004", from /Library/QuickTime. Finally, it worked fine.
What a difficult matter was this! Who can imagine the connection between iPhoto and DivX! What a clever one discovering this! I owe him/her.
11/09/2010
ビデオのコーデック
音楽用や静止画像用のコーデックがわりと単純なのとは対照的に、ビデオのコーデックは複雑怪奇だ。さらにコンテナーという概念も難しすぎる。
最近ではHDのフォーマットが標準的になってきているが、HDといってもひとつじゃない。たとえば、1080iとか720pという表し方をするが、これだけで解像度が決まっているわけではない。フルHDの場合、1920x1080が16:9のピクセル数だが、実際の作業では1440x1080iを用いることがある。しかし、1440x1080は4:3に圧縮された形式で、コーデックを変えた場合に16:9を保つためには1440x810でなくてはならなかったりする。その上、実際には1440x816が使われたりするので、さらにわけがわからない。
QuickTimeでの各種パラメーター設定はなにやらわけのわからないものばかりで、「最適」とはなんのことかも理解出来ない。あまりにもわけがわからなすぎるのに、ろくな解説が見当たらないというのはどうしたものか。
最近ではHDのフォーマットが標準的になってきているが、HDといってもひとつじゃない。たとえば、1080iとか720pという表し方をするが、これだけで解像度が決まっているわけではない。フルHDの場合、1920x1080が16:9のピクセル数だが、実際の作業では1440x1080iを用いることがある。しかし、1440x1080は4:3に圧縮された形式で、コーデックを変えた場合に16:9を保つためには1440x810でなくてはならなかったりする。その上、実際には1440x816が使われたりするので、さらにわけがわからない。
QuickTimeでの各種パラメーター設定はなにやらわけのわからないものばかりで、「最適」とはなんのことかも理解出来ない。あまりにもわけがわからなすぎるのに、ろくな解説が見当たらないというのはどうしたものか。
登録:
投稿 (Atom)