他のツール等でクリップの入力ソースを修正した場合、
キーフレームリストのサルネイムが以前のままです。
特にコマを追加・削除した場合は完全にズレて表示されます。

そこでキーフレームリストのサルネイムを
「最新の情報に更新」
する機能を要望します。

>特にコマを追加・削除した場合は完全にズレて表示されます。
元ファイル：abcdefghijklmnop
キーフレーム：dim
とし、別のソフトでabgopフレームを削除した場合
変更後：cdefijklmn
キーフレーム：fl
となっているのが気に入らないので、
キーフレーム：dim
のままであって欲しいということでしょうか？

かなり説明不足だった様です。申し訳ありません。

>キーフレーム：dim
>のままであって欲しいということでしょうか？

そこまで修正されるなら嬉しいのですが、まずはキーフレームに指定
したフレームのサルネイムが正しく表示されたらと思うのです。

akira_cxさんの例でいうと修正後のキーフレームは[fl]のままでいい
のですが、現行では修正後、
　キーフレームのリスト:
　　既にキャッシュされた[dim]のフレームの映像が表示
　キーフレームのリストの各キーフレームをクリック:
　　[fln]に移動
となっています。

サルネイムの映像には[fl]を表示してほしいと思っています。

本来は完成した素材を入力ソースにすべきでしょうが、チャプタ打ち
用にたくさんキーフレームを登録している際、酷く汚れてる等の気に
入らないフレームがあった場合、その周辺を含めてチョコチョコと別
ソフトで修正してTMPGEncに戻ってくると、サルネイムの映像が、表示
ズレ、または汚い元画像のままといった具合です。

このままエンコしても問題ないと思うのですが、キーフレームの映像
と実際のフレームの映像が違うのは、いかがなものかと思い、
「キーフレームのリスト」の最新表示
があればと思い投稿したしだいです。

雑談なのですが、PS２でDivXの動画を見るにはどのようなファイルを一緒に焼けばいいのでしょうかね？
コーデックはもちろんのこと？ほかにも必要なんですかね？
どなたかやられた方いますか？

PS2(SONY PlayStation2)はDivXデコーダを持っていないので、
MPEG2に変換しない限り再生できません。

また、PS2の発売時期（型番）によっては、MPEG音声に対応して
いなかったり、そもそもDVD-Rメディアを読めないものもあります。


余談ですが…
PS2の開発キットを使ったり、Linuxキットを使えばDivXを再生する
事は実現できるでしょう。（自分でPS2のDivXプレーヤソフトを作る）
しかし、このような質問がでるレベルでは絶対にできないでしょう。

TMPGEnc Plusでは4.7GBに収まるよう自動で設定されますがTMPGEnc3XPではならないのは何故。設定の仕方を教えて下さい。

出力でDVD出力を選べば4.7Gか8.5Gの出力設定が選ばれますよ？
ただ、元のデータの長さが短いとDVD1枚いっぱいまで入れることは元々できないため
4.7Gより少なくなると思います。
逆におもいっきり再生時間が長いと、今度は1枚では収まらないため4.7Gにはなりません。
その辺はPlus2.5とそう変わって無いと思いますよ。

現在、家庭用DVDレコーダー(東芝 RD-XS43)で録画及び大まかなチャプター設定を行った DVD-VR 形式のファイルを XDVD 形式の DVD に変換しようとしています。目的は CM カットと、サイズの低減及び市販DVDプレイヤーでの再生です。

1. TMPGEnc MPEG Editor からのキーフレーム情報の読み込み

TMPGEnc Editor 1.0 でカット編集した MPEG ファイルを XPress 3.0 で読み込む際に、キーフレーム情報が反映されません(DVD-VRのチャプターはキーフレームとして読み込める)。もちろん XPress や Author 単独でもカット編集やフレーム設定はできますが、Editor の快適な操作性は得られません。皆さんはどうされていますか?
＃本掲示板 XPress:2152 でも要望としてはあげられていますが...

とりあえず、以下を試してみました。
(A) 先に XPress でエンコードしてから Editor でフレーム設定を行う
これはできましたが、カットする分もエンコードするのは避けたいところです。また、DVD-VRから読み込んだキーフレーム情報が失われるのも不便です。
(B) Editor のキーフレーム情報を使う
先に Editor でカット編集を行い、XPress では単にエンコードのみを行う。その後 Editor で作成したキーフレーム情報ファイル(*.keyframe)を XPress で出力した mpeg ファイルと同じ場所に置いておき Author で読み込む。手元で試したサンプル(1つ)では、フレームのずれなどは生じていないようですが、これで本当にうまくいくのか...

2. XPress でのキーフレーム情報の出力の ON/OFF 切り替え

XPress の「出力設定」で、キーフレーム設定を情報ファイルに出力するかどうかを切り替えることができますが、デフォルトではこの設定は無効になっています(テンプレートを使えばデフォルトで有効にできる)。しろうと考えではデフォルトで有効にしてもよいのではないかと思うのですが、何らかのデメリット(例:エンコード時間の増加)が考ええられるためでしょうか。

自己フォローです。

ごめんなさい。改行を入れないとブラウザによっては横幅が広がってしまいますね。

質問です。
アニメをavi出力したとき、PCで再生しているのに、横スクロール時のカクカクが出ます。
映像は、２３分３４秒、プログレッシブ、23.976fps、インターレース解除でトップフィールドおよびボトムフィールド、どちらを設定しても同じ現象が起こります。（ソースは問題ない）ソースはトップフィールドが先に表示される。となっています。
ちなみに、フレーム数が変わるとカクカクが直ったり、また別のフレーム数にカットしてエンコードするとカクカクが出たりします。
１フレームずれただけで、この「カクカク」する動きは発生してしまうものなのでしょうか？
あと、オーバーレイがつかえない環境でエンコードしても何か変わるものなのでしょうか？いつもテレビ見ながらエンコードしているので…
いままでは、ボトムフィールドで、滑らかな動画を作成していただけに、
今回の「カクカク」はなんとしても改善したいところです。
長文になりましたが、ご教授のほうよろしくおねがいします。

肝心のキャンプチャー環境が書いてないので、何とも言えません。
・キャプチャー環境
　(フィールドオーダーが正しいかどうか調べるため)
・エンコードしようとしている番組名
　(30fps番組か24fps番組かどうか調べるため)
をお知らせ下さい。

>オーバーレイがつかえない環境でエンコードしても何か変わるものなのでしょうか？
これは関係ありません。

すみません、肝心なことを忘れてしまったようです。。。

キャプチャーは、NECのsmart visionHG/2 15Mbps
番組はスカイパーフェクTVのフジテレビ７２１ 「ワンピース」です。
前までは、ボトムフィールドでインターレース解除をしていたのですが、
最近はバラバラで、トップじゃなきゃいつも通り出来なかったりします。
多分30fpsのトップフィールドオーダーだと思います。（思い込み）

そのアニメが30fpsで作成されていたとするならば、
24fps化するとコマが欠落するのでカクカクするのでは無いでしょうか？

>NECのsmart visionHG/2
だと、『トップフィールドが先に表示される』で問題ないと思います。

>フジテレビ７２１ 「ワンピース」
契約していないので、その番組を見ることができませんが、
縦スクロール画面で30fpsか24fpsかどうか調べてみて下さい。

>縦スクロール画面で30fpsか24fpsかどうか調べてみて下さい。
部分的にＦＰＳを調べられるのですか？
お手数ですが、どのように調べれば良いのでしょうか？

縦スクロールのような連続して動く場面で
5フレームとも連続して動く→30fps
5フレーム中1フレーム動かないフレームがある→24fps
といった具合に調べられます。

akira_cx さん、 ロイ さん、
レスありがとうございます。
akira_cx さん 明日が放送日なので調べてみます！

報告します。
結果、２４fpsということがわかりました。なのにカクカクするのはおかしくないですか？
しかも今回のソースは前回と全く同じ設定にもかかわらず、
あのときの、カクカクは発生しませんでした。
これは、ソースの問題と考えてもいいのでしょうか？

放送されたものであっても素が昔のアナログビデオの場合はアニメ24fを30fに変換して有ります
テロップ等は30fで作ってあります
24f・30fどっちでも好いのですが60fに比べれば当然カクカクします
動き優先24f＋適応補間の使い所はそのために在ります

すみません
せっかく20時間も変換を行って
あと少しのところでinvalid pointer operation
と表示されてしまいました。

これはエラーなのでしょうか？
何が問題だったのでしょうか？

知っていらっしゃる方いらっしゃいましたら
教えてください
お願いします。

http://www.google.com/
Googleにエラーメッセージで検索かけると、何か見えてくるかもしれません。

ＡＶＩファイルからＭＰＥＧ２へエンコードしようと出力開始を始めると、
「ディスクに十分な空き容量がありません」とエラーになってしまいます。
出力先の外付けＨＤＤは１７ＧＢくらいの空きがあり容量には問題ないのですが
「４．１ＧＢの空き容量が必要です」となってしまいます。
Ｃドライブで試したところ出力できました。何故でしょうか？

また速度優先にしてましたがエンコード完了まで１６時間もかかりました。
速度優先にした以外はデフォルト設定で行いましたが
何か設定がおかしかったのでしょうか？
よろしくお願い致します。

ハードディスクが「FAT32」というフォーマットになっていると4G以上のファイルの作成は
どんなソフトでも無理です。
「NTFS」というフォーマットに変換するか、再フォーマットを行ってください。

> また速度優先にしてましたがエンコード完了まで１６時間もかかりました。

16時間の時間がおかしいかどうかは、エンコード元のソースの長さ(時間)とあなたの
PC環境によって変わります。30分程度のソースで最新のPentium4環境(3GHz以上)なら、
16時間掛かるのはおかしいと思いますが、もっと長いソースでもっと遅いPCを使って
いるなら、16時間程度掛かるということも十分に考えられます。

ちょうきさん、fayさん、ありがとうございます。

４Ｇ制限はフォーマットのせいだったんですね、
出力先をＣドライブにしたらできました。

CPUはceleron 2G でソースは約２時間でしたが１６時間は普通でしょうか？

>CPUはceleron 2G でソースは約２時間でしたが１６時間は普通でしょうか？

Celeron 1.3Gマシンを使っていたことがあります。
2時間のDV-AVIファイルをMPEG2にエンコードするのに掛かった時間は、記憶に
よれば以下の通りです。

フィルター無しの2Pass VBRで丸1日弱。（約18時間）
フィルターアリの2Pass VBRで3〜4日。（約50時間）

一晩で終わらないのが嫌になり、Enc専用にPen4/2.4GHzマシンを組みました。
入力ソースがDivX等の重いコーデックだと、もっと時間が掛かるでしょう。
うちはMPEG2→MPEG2か、DV→MPEG2しかやらないので良く判りませんが。

TMPGEnc 3.0 XPress 3.1.2.66に専用 DivX Pro Plug-inを入れてます。
専用 DivX Pro Plug-inを入れる前にもDIGAで録り貯めた映画等をDivX
にしてましたが、しばらくＰＣの熱暴走が怖くて休んでいる間に専用
DivX Pro Plug-inが発売になったので入れて先週末からまたDivXにす
る作業を再開しました。DivX 5.2.1で専用 DivX Pro Plug-inは1.0.1.34
にしてます。

未だに映像部分の最適な設定が分からずに模索してるんですが、出来
る限り仕上がりファイルサイズを押さえる為に音声は48KHz、ステレオ、
48kbsにしてます。以前はこの設定でも特に問題なかったのですが、今
回専用 DivX Pro Plug-inを入れた事で確かMP3エンコーダも変わったと
思いました。このエンコーダの癖なのか同じ設定にすると高周波なノ
イズが入ります。キリキリ音というか３本違う映画で試しましたがどれ
もノイズが入ります。これは設定の問題なのか新しいMP3のエンコーダの
問題なのかが分かりませんが、こちらだけの現象でしょうか？
#Advanced Acoustic Engine MP3 エンコーダって奴ですね＾＾；

既に映像でも何度か試してるんですが、結局素人な自分にはDivX Pro
にした恩恵は全く無く全てデフォルト設定がパフォーマンス的にもあ
っている感じがしました。マルチパスやノイズ除去等は結局エンコ時
間が長い割りに違いが今一分かりませんでした＾＾； このままでは、
専用 DivX Pro Plug-in分全てが無駄になりそうです。せめてMP3エン
コーダのメリットはあればいいのですが、デメリットでは最悪です(T_T)
試しに48kbsではなく96kbsとかでも試しました。96kbsではノイズは
ありませんでした。レートを落とすトレードオフとしてノイズが入る
ってのは以前利用していたMP3エンコーダでは無かった訳なので、これ
が不具合なのか、仕様上諦めるべきのもなのかの回答頂ければ幸いです。

一般的にフラウンフォーファー製MP3エンコーダー（Windowsについてるやつ）はMP3の特許を持つ会社の
特権のようなもので、異常に低ビットレートに強い仕様で有るようです。
公開され、MP3の規格とされている以上の仕組みを取り入れているらしいので、他社製は低ビットレート域では
なかなか音質勝負は難しいようです。

LAMEなどのフリーのエンコーダーと同じくペガシスのMP3も高音質派のようで44khz128kbpsなどの
一般的なMP3設定以上の設定で高音質を発揮するようです。

一般的に高サンプリングレート低ビットレートという設定は行いません。
高サンプリングレートでは必要な情報が多すぎる為、一定以下のビットレートでは再現できません。
フラウンフォーファー製の物では自動的に音を思いっきり削るので実際には48khzの設定の意味をなしていません。
これをせずに実直に再現しようとすると破綻が置き易くなる、と言うことです。
こういう場合はサンプリングレートを下げるのが一般的で、よく使われるのが24Khz56kbps
と言った設定ですね。

またDivXはエンコード時の設定も重要ですがデコード設定（再生時）の設定で画質をおとして
スムーズに再生する　といったモードがONになっている事が多いのでその辺を確認するのも良いかもです。

一般的に、MP3のエンコードではサンプリングレート毎にビットレートの実用の下限が
あると考えます。
私の主観で言うなら、48KHzは128kbps程度、32KHzで96kbps程度、24KHzで56kbps程度が
実用の下限だと思います。これを下回る場合は音質を諦めて聞ければよいと割り切るか、
モノラルにしてしまいます。

ちょうきさん、fayさん、コメントありがとうございます。

お二人とも凄く参考になりました。音質にはあまり拘ってませんので
24KHz 56kbsで試してみます。

>またDivXはエンコード時の設定も重要ですがデコード設定（再生時）の設定で画質をおとして
>スムーズに再生する　といったモードがONになっている事が多いのでその辺を確認するのも良いかもです。

この点もチェックしてみますm(__)m

すみません。TMPGEncをはじめて使うのですが、
色々ページを見てもわからないかったので
質問させてください。

avi→mpeg2へ変換をしているのですが
見積もりで40時間とか平気で越えてしまう状態です。
なるべく質を落とさず、短くする方法や
一時変換をやめて、後日またそこから変換を始められたりもするのでしょうか？

初心者でもわかるWEBページがありましたら
教えてください

よろしくお願いいたします。

検索：エンコード時間
http://bbs.pegasys-inc.com/bbscgi/search/namazu.cgi?query=%A5%A8%A5%F3%A5%B3%A1%BC%A5%C9%BB%FE%B4%D6&whence=0&lang=ja&max=20&result=normal&sort=score&idxname=ja%2Fte30

検索：一時停止
http://bbs.pegasys-inc.com/bbscgi/search/namazu.cgi?query=%B0%EC%BB%FE%C4%E4%BB%DF&whence=0&lang=ja&max=20&result=normal&sort=score&idxname=ja%2Fte30

検索：中断
http://bbs.pegasys-inc.com/bbscgi/search/namazu.cgi?query=%C3%E6%C3%C7&whence=0&lang=ja&max=20&result=normal&sort=score&idxname=ja%2Fte30

検索：再開
http://bbs.pegasys-inc.com/bbscgi/search/namazu.cgi?query=%BA%C6%B3%AB&whence=0&lang=ja&max=20&result=normal&sort=score&idxname=ja%2Fte30

Google：TMPGEnc 使い方
http://www.google.com/search?hl=ja&ie=S-JIS&oe=S-JIS=1&q=TMPGEnc%20使い方&lr=lang_ja

検索機能を使うと良いでしょう。

No.50126, 1799 の質問、要望とかぶるのですが、
TMPGEnc Plus 2.5の「YUVデータをCCIR601ではなく、Basic YCbCrで出力する」の
機能を要望します。

自分の使い方としては、
1. MTV1000でMPEGキャプチャ
2. aviutlで編集し、プロジェクト保存。
3. TMPGEncでMPEG再圧縮
のような使い方が多いのですが、基本的にキャプチャしたときのままの
色で出力したいと思っています。

2でPCスケールに変換すればよいとは思うのですが、なるべくなら無駄な変換は
したくありません。

以上、よろしくお願いします。

VFAPIで誤解があるかもしれまん。

AviutlからTMPGEncへVFAPIを経由してデータを渡す場合
Aviutlに投入の時点でMPEGの16〜235をPCスケール（0〜255）にしていると
0〜15、236〜255にMPEG時に存在していたデータはRGB化（VFAPI経由時）で消えます。
ですので、
>2でPCスケールに変換すればよいとは思うのですが、
これは行わないのが正解だと思います。

「3」でTMPGEncの色補正でいい感じに設定してエンコードするのが現在の一番いい手
となりますね。

あとは、全部の作業をTMPGEnc 3.0でするか　かな。

TMPGEnc 3.0は入力をYUVにさえすればRGB仕様のフィルタを通過しなければ
YUV0〜255はMPEG圧縮後も0〜255有るんで、VFAPIとか非圧縮AVIなどを使わない方向を
考えるのも良いかもしれません。

＞ちょうきさん

http://www3.tcn.ne.jp/~rakka/temp/src.png
ソースのMPGファイルのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp/2.5.png
TMPGEnc Plus 2.5で「YUVデータをCCIR601ではなく、Basic YCbCrで出力する」を
ONにして出力したMPGファイルのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp/3.0.png
TMPGEnc 3.0 XPressで出力したMPGファイルのヒストグラム

上の結果からTMPGEnc 3.0では、PC->TVスケール補正が行われているものと
判断しました。

自分としては、色合いについて主観で良いか悪いか判断できないので、
なるべくソースと同じヒストグラムになるように出力したいと思っています。

ですので、aviutlでTV->PCスケール補正をかければ、情報量は減りますが
まだましなものができるのでは？と思いました。
TMPGEncでも色補正できますが、TMPGEncでTV->PCスケール補正と
同等の補正を行うのは手間がかかりすぎるように思いますし、
また、TV->PCスケール補正後と同様のヒストグラムになるように
補正をかければ、結局、情報量は同じだけなくなるように思うのですが
どうでしょうか？

この辺は難しいのですが
MPEG圧縮は基本的にRGB0〜255をYUV16〜235として圧縮し、再生時に0〜255として再生するのが基本です。
（ですので、まるもデコーダーとかにはストレート変換（16〜235のまま）やCCIR601伸張（規定の伸張作業）の2個が有ったりします。）
再利用用のCRIデコーダーやまるもデコーダーなどは別として、最終的な再生側はDVDプレーヤー
であったり、DVD-MPEG再生ソフトであったりします。
この場合CCIR601伸張が基本となります。（CCIR601伸張された絵が正解）
つまりMPEGではCCIRの圧縮・伸張は1セットと言う事です。

この再利用時の伸張作業なのですが、Aviutlに読み込ませる前のデコーダーで行う場合、Aviutlで行う場合、
TMPGEnc 3.0 XPress(以下3.0)で行う場合の3つが考えられます。

私はこの3つ目の3.0に来てから、色調補正内の「YUVのCCIR伸張」で輝度・色差を両方とも255にするという
作業でCCIR伸張（つまりPCスケール変換）を行うのが良いのではないかなと思うわけです。

いずれにせよ「YUVデータをCCIR601ではなく、Basic YCbCrで出力する」が無い現状では
上記作業でRGBソースをYUVにすると0〜15、236〜255に存在していたソースは無くなります。
でも精度的にVFAPIを一度介すよりも3.0内で行った方がいいのでは無いかと思うわけです。

まぁ今回のケースで一番いいのは、VFAPIを介さず、HuffyuvなどでAviutlから一度出力して
それを3.0に読み込ませればYUVソースとして扱われるのでデータは全部残るんでは無いかな
と思います。（VFAPI経由は重いので実質のエンコード時間はhuffyuv出力時間を入れても減るかも）

>私はこの3つ目の3.0に来てから、色調補正内の「YUVのCCIR伸張」で輝度・色差を両方とも255にするという
>作業でCCIR伸張（つまりPCスケール変換）を行うのが良いのではないかなと思うわけです。

実際に試したところ、aviutlでTV->PCスケール補正をかけたのと同じヒストグラムに
なりました。TMPGEnc 3.0の色調補正で簡単に同様のことができるとは
知りませんでした。

>まぁ今回のケースで一番いいのは、VFAPIを介さず、HuffyuvなどでAviutlから一度出力して
>それを3.0に読み込ませればYUVソースとして扱われるのでデータは全部残るんでは無いかな
>と思います。（VFAPI経由は重いので実質のエンコード時間はhuffyuv出力時間を入れても減るかも）

なるほど。huffyuv形式のaviファイルは色情報をYUV形式で持っているので
TMPGEncはMPGファイルと同様にCCIR圧縮を行わないのでは？ということですね。
多少、作業が増えますが、できれば自分の期待する形で出力できますね。

いろいろと役に立つ情報、ありがとうございました。

ただ、やはりTMPGEncとしては、VFAPIから入力されたデータがMPGファイルで
あることも考慮して、CCIR圧縮を行わないという設定をできるように
して欲しいと思っています。

Huffyuv v2.1.1をインストールし、設定は特に変更せずに
Huffyuv形式でavi出力し、TMPGEncに入力し、DVD NTSC形式で出力したのですが
CIIR圧縮されていました。

とりあえず今のところは、TMPGEncでCCIR伸張するしかないのかもしれません。

間違っていました。
HuffyuvもYUVなので、Hufyuv化時にRGB＞YUV変換が入ります。（16〜235になる）
これを回避するには・・・・

Basic YCbCrで保存　に相当する機能の有る HuffyuvS を使うとか・・・（0〜255のYUVで保存するHuffyuvの派生）
うーんややこしくなってきました(^^;

>Basic YCbCrで保存　に相当する機能の有る HuffyuvS を使うとか・・・（0〜255のYUVで保存するHuffyuvの派生）

HuffyuvSで検索してみたところ、

huffyuvs 0.6 left origin base2.1.1
huffyuvs 0.6 left origin base2.1.1 ccesp

の2つが見つかったのですが、どちらを使えばよいのかわかりませんでした。
名前からするとccespはCCE-SP用に出力する場合？のように思われるのですが
ネットで見つかったページを見ているとccespでよいようにも思います。

ccespでよいのでしょうか？

ごめんなさい、寝ぼけてました。

Aviutlの98d辺りのバージョン以降を使っておられるなら、まるもさんのデコーダー
m2v.vfpをm2v.auiとリネームしてAviutlのフォルダへ置くことでYUV読み込みが可能になります。
これで元のYUVデータを維持してYUV読みこみ出来ているので、そのままHuffyuvへ出力し、
TMPGEncでもYUVで読み込む事でRGB変換を経ずに受け渡すことが出来ます。
この方法であればhuffyuvSは使わずにすみますね。

m2v_vfp-0.6.48.lzh
huffyuvs_0.6_-_left_origin_-_base2.1.1-ccesp_dll.zip
をインストールし、試してみたのですが、
出力されたMPEGファイルはCCIR601圧縮されていました。
m2v.aui、huffyuvsの設定はデフォルトのままで特に変更していません。

えっと、こんがらがらせてすみません。huffyuvSは忘れてください（^^;

以下の文では
Aviutl99およびAviutl98d、そしてまるもプラグインm2v_vfp-0.6.48とHuffyuv2.20を使用して居ます。

まず結論からですが
http://www.delmart.org/~tyouki/img/aui_non.png
上のヒストグラムのように、m2v_vfp-0.6.48のm2v.vfpを「m2v.aui」へリネームし
Aviutlのフォルダに設置し、MPEGファイルを読みこみ、それをHuffyuvで出力した物を
XPressへ読み込んだ物です。

全部YUV処理なのでCCIR圧縮は経ずにデータのやり取りが可能です。

ここで一歩踏み込んだ話を始めます。
まず
http://www.delmart.org/~tyouki/img/aui_set.png
これを見てください。
先ほどのaui_non.pngのデータをXPressで色データがどこまで残っているか　を見るために
CCIR伸張の項目でマイナス方向へセットした物です。
（再生時にはaui_non.pngの状態で見るので、このaui_set.pngの図は、より精度をのためにと考えてください。）
Aviutl98dで処理した物は乱れが出て居ます。
これはAviutl99で仕様変更となったAviutl98dのYUVの飽和の設定のせいです。
現在は精度的には99、安定性は98dと言われています。

今度はまるもデコーダーをVFAPI経由で動作（RGB処理）で動かして見ます。
http://www.delmart.org/~tyouki/img/vfp_non.png

一番最初の（http://www.delmart.org/~tyouki/img/aui_non.png）と比べても
CCIR伸張済み>Huffyuvのデータもストレート変換後Huffyuv化しXPressの色補正でCCIR伸張した物
は同じように見えます。
ストレートのものはCCIR圧縮されたままなので左右端に隙間が出来ています。

しかし、色データがどこまで残っているか調べる為にCCIR伸張の項目でマイナス方向へセットすると
http://www.delmart.org/~tyouki/img/vfp_set.png
こうなります。
デコーダでCCIR伸張後にデータを受け渡すと左右端に存在するデータが消し飛んでいます。

この結果からAviutlとXPressを使用する場合
・Aviutlプロジェクトを使う場合（またはm2v.vfpを使う場合）はストレート変換+XPressでのCCIR伸張
・Huffyuvを使う場合はm2v.vfpをm2v.auiにしてHuffyuvへYUV処理のままXPressへ

この2個が劣化が少なくてすむやり方ですね。

● 使用ソフトのバージョン
TMPGEnc 3.0 XPress Trial Version 3.1.2.66
AviUtl 0.99
Huffyuv v2.1.1
m2v_vfp-0.6.48

● 使用ソフトの設定
http://www3.tcn.ne.jp/~rakka/temp2/setting_m2v_aui.png
m2v.auiの設定

http://www3.tcn.ne.jp/~rakka/temp2/setting_Huffyuv.png
Huffyuvの設定

● CCIR伸張の項目でマイナス方向へセットした物について
http://www3.tcn.ne.jp/~rakka/temp2/src_aviutl.png
m2v.auiの設定を「ストレート変換」にし、
aviutlでsrc.m2vを読み込みんだときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp2/src_TMPGEnc.png
http://www3.tcn.ne.jp/~rakka/temp2/src_TMPGEnc(CCIR601).png
TMPGEncでsrc.m2vを読み込んだときのヒストグラムと、フィルターの
色調補正のCCIR601伸長で輝度、色差を-255にしたときのヒストグラム

http://www.delmart.org/~tyouki/img/aui_non.png
http://www.delmart.org/~tyouki/img/aui_set.png
ちょうきさんの結果の「オリジナル」のヒストグラムを見た感じでは、
aui_set.pngにおいて236〜255の値が現れていますが、
自分の結果では0になっています。
aui_set.pngは、どのようにした場合のヒストグラムになるのでしょうか？

● Huffyuv->TMPGEncについて
1. m2v.auiの設定を「ITU-R BT.601から伸張」に戻し、
aviutlでsrc.m2vを読み込み、avi(Huffyuv)ファイルを出力する。
2. avi(Huffyuv)ファイルをTMPGEncで読み込み、m2vファイルを出力する。

のようして作成されたm2vファイルのヒストグラムを見てみました。

http://www3.tcn.ne.jp/~rakka/temp2/Huffyuv_TMPGEnc.png
TMPGEncで読み込んだときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp2/Huffyuv_aviutl.png
aviutl(ストレート変換)で読み込みんだときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp2/src_TMPGEnc.png
http://www3.tcn.ne.jp/~rakka/temp2/Huffyuv_TMPGEnc.png
CCIR伸張されているTMPGEncのヒストグラムを見比べると
ソースとほぼ同じなのですが、

http://www3.tcn.ne.jp/~rakka/temp2/src_aviutl.png
http://www3.tcn.ne.jp/~rakka/temp2/Huffyuv_aviutl.png
CCIR伸張されていないaviutlのヒストグラムを見比べると、
236〜255の情報が失われているようでした。

http://www.delmart.org/~tyouki/img/aui_set.png
ちょうきさんの結果の真中の列を見た感じでは失われていないよう
なのですが、自分の処理方法、設定に問題があるのでしょうか？

>ちょうきさんの結果の「オリジナル」のヒストグラムを見た感じでは、
>aui_set.pngにおいて236〜255の値が現れていますが、
>自分の結果では0になっています。

これには裏技が有ります。
TMPGEnc 3.0 のフィルタ画面の下のオーバーレイ　をONにします。
すると、今までRGB0〜255表示だったヒストグラムが　-16〜0〜255〜275分表示可能になります。
と言っても表示されているのは0〜255の範囲なので明るさとかを下げたりCCIR逆操作を行ったりすると
ズルズルズルっと隠れていた分が出てきます。
なぜこう言う仕様なのかは知りませんが、推測するにYUV対応時の隠しモードかと。
私はG550などのグラフィックカードでTV出力時の色とかも見て色調整するのでこのモードには
気が付きました。
こっそり使ってます。

>http://www3.tcn.ne.jp/~rakka/temp2/src_TMPGEnc(CCIR601).png
こちらのヒストグラムの状態でオーバーレイをON,OFFすれば右の絶壁がなだらかになると思います。

aui読みこみの際はYUVで読み込むのでCCIR伸張は全く不要です。
YUV0〜255がYUV0〜255で扱われます。これをAviutlでHuffyuvで出す時はファイル＞環境設定＞コーデックの設定で
HuffyuvがYUY2で圧縮　にチェックが入っている事を確認して置いてください。
これをTMPGEncで読み込んでください。
ヒストグラムでのチェックはTMPGEncでもう一回ためして見てください。

>これには裏技が有ります。
>TMPGEnc 3.0 のフィルタ画面の下のオーバーレイ　をONにします。
>すると、今までRGB0〜255表示だったヒストグラムが　-16〜0〜255〜275分表示可能になります。
>と言っても表示されているのは0〜255の範囲なので明るさとかを下げたりCCIR逆操作を行ったりすると
>ズルズルズルっと隠れていた分が出てきます。

オーバーレイをONにしたところ、CCIR圧縮したときに236〜255の値が
表示されるようになりました。

>aui読みこみの際はYUVで読み込むのでCCIR伸張は全く不要です。
>YUV0〜255がYUV0〜255で扱われます。これをAviutlでHuffyuvで出す時はファイル＞環境設定＞コーデックの設定で
>HuffyuvがYUY2で圧縮　にチェックが入っている事を確認して置いてください。
>これをTMPGEncで読み込んでください。
>ヒストグラムでのチェックはTMPGEncでもう一回ためして見てください。

http://www3.tcn.ne.jp/~rakka/temp3/setting_aviutl_codec.png
aviutlのコーデックの設定です。

http://www3.tcn.ne.jp/~rakka/temp2/src_TMPGEnc.png
ソースのm2vファイルをTMPGEncで読み込んだときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp3/Huffyuv_avi_TMPGEnc.png
aviutl(ストレート変換)でソースのm2vを読み込み、出力したaviファイルを
TMPGEncで読み込みこんだときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp3/Huffyuv_m2v_TMPGEnc.png
TMPGEncで上のaviファイルを読み込み、出力したm2vファイルを
TMPGEncで読み込んだときのヒストグラム

ソースのm2vファイルを読み込んだときのヒストグラムはCCIR伸張されているのですが
aviファイルを読み込んだときのヒストグラムはCCIR伸張されていませんでした。
そのためか最後に出力したm2vファイルのヒストグラムは、ソースのヒストグラムを
CCIR圧縮したようなヒストグラムになっていました。

http://www3.tcn.ne.jp/~rakka/temp3/setting_TMPGEnc1.png
http://www3.tcn.ne.jp/~rakka/temp3/setting_TMPGEnc2.png
TMPGEncの環境設定の入力プラグイン設定、AVIコーデック設定は
上のようになっているのですが、これの設定が関係しているのでしょうか？

http://jumper-x.hp.infoseek.co.jp/begin/column/2/
MPEG-2 VIDEO VFAPI Plug-Inの使い方

http://jumper-x.hp.infoseek.co.jp/study/6/index.html
YC伸張実験君

のページを見ていたところ、どうもAviUtlの入力プラグインの優先度の
設定が関係しているように思いました。
たぶん、MPEG-2 VIDEO Plug-InよりもMPEG-2 VIDEO File Readerの
優先度が高くないといけないと思うのですが、もしかすると
そうなっていないのかもしれません。
（現在、自宅にいないので確認できません。）

aviutlの入力プラグインの優先度の設定を見たところ、
・MPEG-2 VIDEO Plug-In
・MPEG-2 File Reader
のようになっておりm2v.vfpが使われているようでした。
MPEG-2 File Readerの優先度を上げ、上と同じようにした
結果、下のようになりました。

http://www3.tcn.ne.jp/~rakka/temp4/src_TMPGEnc2.png
src.m2vをTMPGEncで読み込みCCIR601圧縮したときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp4/src_m2v_TMPGEnc2.png
src.m2vをTMPGEncで読み込み、出力したm2vファイルを
TMPGEncで読み込みCCIR601圧縮したときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp4/Huffyuv_m2v_TMPGEnc2.png
src.m2vをaviutlで読み込み、出力したavi(Huffyuv)ファイルを
TMPGEncで読み込み、出力したm2vファイルを
TMPGEncで読み込みCCIR601圧縮したときのヒストグラム

ヒストグラムはほぼ同じなので、Huffyuvを中間ファイルとして
出力すれば、とりあえずTMPGEnc Plus 2.5の
「YUVデータをCCIR601ではなく、Basic YCbCrで出力する」で
出力したのと同じような結果が得られることがわかりました。

ただ、Huffyuvを中間ファイルとして出力するためには空き容量が
結構いるので、Huffyuvを中間ファイルとして使わない方法についても
試したいと思います。（試用期間が残り少ないので厳しいですが）

>この結果からAviutlとXPressを使用する場合
>・Aviutlプロジェクトを使う場合（またはm2v.vfpを使う場合）はストレート変換+XPressでのCCIR伸張
>・Huffyuvを使う場合はm2v.vfpをm2v.auiにしてHuffyuvへYUV処理のままXPressへ

の上の方法について。

1. aviutlの入力プラグインの優先度の設定において、MPEG-2 VIDEO Plug-In(m2v.vfp)の
優先度をMPEG-2 File Reader(m2v.aui)よりも上にする。
2. m2v.vfpの設定を「ストレート変換」にする。
3. src.m2vをaviutlで読み込み、プロジェクトファイルを出力する。
→ src.aup
4. src.aupをTMPGEncで読み込み、CCIR601伸張し、m2vファイルを出力する。
→ src_aup.m2v

のようにしたときのヒストグラムは以下のようになりました。

http://www3.tcn.ne.jp/~rakka/temp5/src_TMPGEnc2.png
src.m2vをTMPGEncで読み込み、CCIR601圧縮したときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp5/src_aup_TMPGEnc.png
http://www3.tcn.ne.jp/~rakka/temp5/src_aup_TMPGEnc2.png
src.aupをTMPGEncで読み込んだときのヒストグラムと
CCIR601伸張したときのヒストグラム

http://www3.tcn.ne.jp/~rakka/temp5/src_aup_m2v_TMPGEnc2.png
src_aup.m2vをTMPGEncで読み込み、CCIR601圧縮したときのヒストグラム

最後のヒストグラムとソースのヒストグラムを見比べた感じでは、
235〜のデータがなくなっているように思います。

>・Aviutlプロジェクトを使う場合（またはm2v.vfpを使う場合）はストレート変換+XPressでのCCIR伸張
の方法は、上の1〜4の操作とは異なるのでしょうか？

>>・Aviutlプロジェクトを使う場合（またはm2v.vfpを使う場合）はストレート変換+XPressでのCCIR伸張
>の方法は、上の1〜4の操作とは異なるのでしょうか？

これは、aupを読んでるという事はTMPGEnc3.0がRGBモードなので
ヒストグラムで０〜２５５に見えている範囲が全てと言う事になりますね。
ですんでTMPGEnc3.0をYUVモードで動かす事が肝要ってことだと思います（Huffyuv経由）

>この結果からAviutlとXPressを使用する場合
>・Aviutlプロジェクトを使う場合（またはm2v.vfpを使う場合）はストレート変換+XPressでのCCIR伸張
>・Huffyuvを使う場合はm2v.vfpをm2v.auiにしてHuffyuvへYUV処理のままXPressへ
>
>この2個が劣化が少なくてすむやり方ですね。

のように書かれている2つの方法の上の方法については、
Huffyuvを経由する方法ではないように思ったのですが違うのでしょうか？

一応、aup入力だとRGB入力になって、Huffyuv入力だとYUV入力になることは
これまでの議論？で理解しています。
結局のところ、全く損失なくMPEG出力する場合、
Huffyuv入力するしかなく、aup入力する場合は235〜の損失は避けられない、
ということでよろしいでしょうか？

>Huffyuv入力するしかなく、aup入力する場合は235〜の損失は避けられない、
そう言うことだと思います。
二転三転してすみません（^^;

圧縮してあるアニメ（24分が14ファイル）を1本のDVDにまとめようとTMPGEnc 3.0 XPressでDivXでMPEG2に変換（AC-3使用）したら1部のファイルは音が出ないし、異様に重くて再生できないファイルもあり、音がずれてる（セリフと声があっていない）など不具合の連続です。

なお、元のDivXで圧縮してある動画（.avi）は正常に再生できます。
（WMP10、HAKOBAKO Playerで確認しました。）

正常にMPEG-2で出力する方法、また原因として考えられることなど
分かりましたら教えてください。

よろしくお願いします。

>正常にMPEG-2で出力する方法、また原因として考えられることなど
>分かりましたら教えてください。
(最近のWinnyで流通しているものにありがちな)120fps+AC-3だとか？

回答ありがとうございます。
ファイルは24fpsで音声はMP3 128kbpsです。
（120fps+AC-3ではありません）

http://www.pegasys-inc.com/ja/product/te3xp_spec.html
仕様一覧に
>※1 無圧縮AVIファイルに対応。その他のAVIファイルは導入されているコーデックに依存します。
>※ 音声に特殊形式（VBR、ogg等）の物を利用している場合、音声がずれたり出力されない場合があります。
と書いてある通り、圧縮されているファイルでは、動作保証はないようです。

というわけで、
>正常にMPEG-2で出力する方法、また原因として考えられることなど
>分かりましたら教えてください。
・圧縮する前のファイル(キャプチャ直後のファイル)からエンコードして下さい。
・音声にVBRを使わないで下さい。
といったところでしょうか。





※以下は呟きですので、気にしないで下さい。
同じ方法でDivX化(エンコード)していたら、
>DivXでMPEG2に変換（AC-3使用）したら1部のファイルは音が出ないし、
>異様に重くて再生できないファイルもあり
と個体差なんて出ないはずなのですがね・・

コーデックは同じDivXでも、最新版が出たら入れ替えたり、雑誌でこういう設定のがいいって書いてあったらそれを試したり…って感じで、結構設定を変えて試行錯誤している段階のときに放送していたアニメですので…。

圧縮されているファイルでは、動作保証はないってのはショックです。
キャプチャーしたファイルはDivXに圧縮して、削除してしまいましたし。

どうしましょう…。これらのファイルをMPEG2にすることは不可能なのでしょうか？

そのうちMPEG2にしてDVD化することを考えてなかったんだね。
DivXは最終保存形式なので、そこからさらに変換なんて考えるのはやめましょう。
先を見る眼が甘かったですな。　：P

さて、やるとしたらこんな手段でしょうか。

・DivXを再生して、アナログ出力をして、キャプチャしなおす
・プレーヤの再生映像をそのままキャプチャするソフトを使って、キャプチャしなおす
・再放送やセル版が出るのを待つ
・あきらめて、DivXが再生できるDVDプレーヤを買ってきて、TVではそれで見る

4つ目がお勧めかな。画質はこれ以上劣化しないし。

ちなみに…
大切な物は、しばらくは将来性に問題無いMPEG2の高ビットレートで保存したり、
画質を超重視する人はhuffyuvで可逆圧縮したりして保存しています。
そういう人達は金に糸目をつけません。と、いいつつもHDDは安くなってますから
たいした金かけなくても大量に保存できる時代になってますよね。

私は…
特に映画とかだと、TVキャプチャして編集して…なんて面倒になったので、DVDが
売っていたら買ってきちゃいます。
TV番組はHDレコーダで録りまくってます。保存はHDDがいっぱいになってから考えます。

>キャプチャーしたファイルはDivXに圧縮して、削除してしまいましたし。
この時点で、DivXにエンコードしたもので満足されたから元のファイルを消したのですよね？

>コーデックは同じDivXでも、最新版が出たら入れ替えたり、雑誌でこういう設定のがいいって書いてあったら
>それを試したり…って感じで、結構設定を変えて試行錯誤している段階のときに放送していたアニメですので…。
今後、試行錯誤している時は、満足されるまで元のファイルを消さないことをお勧めします。

※そういう意味では、ちょこちょことVerUPを繰り返すDivXは怖くて使えませんね。

やすべ〜 さんに質問ですが　音声をWAVEに切り出して変換＞エンコ…はしましたよね？
またはAVIUTLなどで再出力してもダメだったんでしょうか？　その後どうですか

HAKOBAKOPLAYRで困っていたファイルが再生できたのはいいんですが、音が流れません・・・。どうすればいいでしょうか教えてください。宜しくお願いします。

これをやってみてください。
http://www.hatena.ne.jp/1094658238

TMPGEnc3.0XPressでのWMV9(29.97fps インターレース)出力なのですが、
どのように設定してもインターレース解除されたような映像になります。
テロップなどが判り易いのですが、片方のフィールド情報が欠落したような
映像になります。
WMエンコーダーより便利なのでうまく使えるようになりたいです。
アドバイスをお願いします。

WMV9でインターレース出力して、それをメディアプレイヤーで再生して確認したのなら、
インターレース解除されたような映像になることもあります。それはプレイヤーが勝手
に行っていることなので作る側ではどうにもなりません。出力したファイルをもう一度
TMPGEnc 3.0 XPressで読み込ませてみて、インターレース縞が残っているかどうか確認
するのが良いでしょう。

またWMP10にはビデオカードの機能を使ってインターレースのWMVを綺麗に再生する機能
があると聞いたことがあります。その機能は対応ビデオカードとレジストリの修正が
必要だということで私は試したことはありませんが、WMP9時代に作ったインターレース
のWMVファイルも綺麗に再生できるとのことなのでGoogleなどで検索してお試しください。