こんにちは。
先日までXviDを使ってエンコしてたのですが今日急に使えなくなってしまいました。
ファイルに出力→aviでXviDを選択で保存をクリックすると「モジュール"xvid.dll"のアドレス 074A3653 でアドレス 9D376A64 に対する読み込み違反が起きました」と表示されてしまいます。
どうすれば直るのでしょうか？

追加です。

先ほどXviDをアンインストールしてまた入れなおしてみましたが症状は変わりません。
DivXで試したのですがDivXでは何も問題無くエンコは終了しました。

誰か「これが原因では？」と思うお方は教えてください。
協力お願いします〜

「先日」から「今」までの間に自動、手動併せてインストール（アンインストール）したものは無いですか？
レジストリの消去や手動変更などはしていませんか？

使えたものが突然使えなくなるってのは大概どっちかをしたために起きるようですよ

ピンポイントで情報書くのも良いですが、OSなどの「周り」も書かれないと何とも言えないかとも思います

XviDってのは直接インストールしたことは無い（けど、登録されている・・・なぜだ？）ので何とも言えませんがアンインストール後にレジストリのゴミとかは無かったんですよね？
ものによってはアンインストール後の再インストールを予期して設定などを保存したままなんてものがあるようですよ

夢魔特急さんの環境にXvidが登録されているのは、
Davideoをインストールしたからだと考えられます。

余談でした(笑)

詳しいことを書くのを忘れていました・・・
OSはWindowsXP homeです。
メモリは512Mです。

アンインストした物ですか〜
何もアンインストしてないですけどねぇ〜
いったい何が原因なんでしょうか？
分からないなぁ・・・

ソフトのバグでもない限り、原因の特定は難しいかも知れません。
下記の方法を試してみて下さい。

１．XviDだけでなく、TMPGEncもアンインストールし、両方再インストールしてみる。

それでダメなら、

２．両方アンインストールし、（関連する）残ったファイルをフォルダごとバッサリ
削除する。その後再インストール。

まだだめなら、

３．両方アンインストール、ファイル・フォルダを削除した後、レジストリエディタ
にて残ったレジストリキーを削除する。その後再インストール。

これでイケるんじゃないかと思いますが・・・

経験上、この程度でシステムがおかしくなる事はないと思いますが、保証はできませ
ん。もし、Norton SystemWorks等のシステムユーティリティをお持ちでしたら、修復
しながら作業する事をお勧めします。又、システムの復元やレジストリのバックアッ
プも行った方が良いでしょう。

私は、仕事でも一日中ビジネスアプリを扱っており、様々なエラーに悩まされてきま
したが、このようなエラーは上記の方法で大抵直ります。（あくまで「大抵」ですが）
システムを弄り回していて、「危険な行為」は大分判るようになってきましたが、そ
れでもOSをクリーンインストールせざるを得なくなった事が何度もありますので、レ
ジストリを弄る時は、あくまで自己責任でお願いします。

方法を紹介しておいて、「自己責任で」とは無責任なようですが、ご容赦下さい。

的外れかもしれませんが、Xvidにはいろいろなビルドがあるようですね。
ほかのビルドで試してみる、というのもひとつのテかもしれません。

#AviUtilでエラーが出ないようでしたら、プロジェクトファイル経由で
#そちらを使うというのも。

親切に教えていただきありがとうございました〜
今は友達の家に来ている為、自宅に戻らないと教えてくださった事が試せません(笑)
自宅に帰り次第、試してみますね。
もしそれでも直らない場合はOSのリカバリーするしかないなぁ〜

大事な事忘れてました！
WinXPですよね？ おかしくなったのは今日という事ですので、「システムの復元」で
少し遡れば直るかも知れませんよ。

TMPGEncを使ってmov→mpeg変換をしているのですが、
３２０×２４０　３０ｆｐｓの動画を変換する時に
大体３００ｋｂｐｓ以下に落とすと、
変換後の動画が、最終フレームが長く表示され、その分データ量が増えてしまいます。
３００ｋｂｐｓ以下ではデータレートを変えても最終フレームが表示される時間が変わるだけでファイルサイズが同じになります。
なぜでしょうか？

私自身詳しい訳ではないのですが、ビットレートって絵の綺麗さみたいなものの指標だと理解しています
ですので、ビットレートを落としたとしても結局作る枚数（フレームレート？）が変わっていないのだからある一定量以下には落とせないのだと思いますよ
多分「これ以上落としても意味がない」ってボーダーラインみたいなものがあるのかな？
それが３００ｋｂｐｓ？

落とした場合の現象から考えると、どうやら違うっぽいですね（なら書くな？ごもっとも）

同様のことを短いソース(15秒ほど)で確認してみました。
元ソースは4MほどのMPEG-1ファイルです。
CBR300kで320×240、30fpsで作ったもの=900kほど
CBR150kで320×240、30fpsで作ったもの=600kほど
ちなみに音声は両方とも192kで(笑)作りましたが、
ファイルサイズはビットレート相応に変化し、状況は再現しませんでした。

つまり、これはすべてのソース、環境で起こるものではない、というご報告です。

もももさんの環境では、ソースを変えても同様になりますか?
ソースによるのか、環境によるのか、切り分ける必要があると思います。

ソースによって多少限界のビットレートは違いますが全部この現象が起きます。
ビデオのビットレートを０、オーディオを３２ｋｂｐｓでやってみたら
１４秒の動画が１分をこえました！
ビットレートはちゃんと変化しているのですが時間が増えるのです。
なんなんでしょう？

ああ、movなのですね。
movだったらTMPGEncに読み込ませる前にQuickTime Pro
(や、ほかのビデオ編集ソフト)でAVIに変換したほうが
ヨイのではありませんか?

以下余談
なんで、デジカメとかはQuickTimeを採用しちゃってるんでしょうね?(笑)
EggyとかSHARPザウルスとかに採用されてるMPEG-4+G.726なASFとかでも
そんなに悪くなさそうですけれどねえ。Appleがライセンス
ばらまいたりしてるんでしょうか(笑)

アスペクト比とは出力画像サイズを
どのくらいの比率で表示させるかの
設定だと理解しているのですが、
ＦＡＱに推奨アスペクト比として
下記のような内容が書かれていますが、
どうして、320×240の場合は1:1（VGA)、
352×240の場合は4:3 NTSCが良いので
しょうか？その理由を教えてください。
また、320×240に対して4:3 NTSC、
352×240に対して1:1(VGA)を設定した
場合、それぞれの画像はいくつ×いくつ
で表示されるのでしょうか。
もし、計算方法があるのであればそれも
教えてください。

宜しくお願いいたします。

解像度 推奨アスペクト比
320x240 1:1 (VGA)
352x240 (Video-CD) 4:3 NTSC
640x480 1:1 (VGA)
720x480 (DV, DVD) 4:3 NTSC

アスペクト比とは単純に画像の縦横比ではありません。
MPEG-1の場合アスペクト比とはピクセル比率を指す場合があります。
PCの場合は1ピクセル（1ドット）が正方画素ですから320×240で
ちょうど4：3の縦横比になりますが352×240では横長になってしまいます。
352x240 4:3 NTSCとはTVで見た時に4：3になるような設定です。
ただしMPEGファイルにアスペクト情報を持つことが出来るので
この情報を正しく認識できる再生ソフトであれば352×240でもPC上で4：3で再生できます。
ですから352×240 1:1(VGA)だと縦横比は22:15になります。

あまり詳しくない上に言葉足らずのレスで申し訳ありません。

DVD-Rオーサリング後の 下記Panasonic E10レコーダ再生状態について
知っている方いましたら、教えて下さい。

通常、DVD-Videoを再生すると、タイムカウンターが表示されて、現在の
再生時間がわかります(大抵のプレイヤーもそうだと思います)。この状態
だと、再生途中で中断した場合(電源を切った場合orポーズを長い時間行った
場合)、その途中から再生できる仕様になっています。が、VCD の再生では、
「PLAY」と表示され、中断した場合、途中からの再生ができず、頭からの
再生となってしまいます。で、本題ですが、TMPEGEnc を 固定品質(CQ)で
エンコードし、DVDit にてオーサリングしたもので DVD-Video(DVD-R)を
作成すると、VCD と同様で、再生時にタイムカウンターが表示されません。
もしかしたら固定品質(CBR)でエンコードしないと・・・とも思いますが、
CQ だと大容量(３時間)とかでもきれいにエンコードしてくれるので
このモードを使用していきたいのですが・・・。

この手の問題の多くはオーサリングソフトとDVDプレーヤの相性のような気がします。
他のオーサリングソフトを使ってみてはどうでしょう。

また、TMPGEncの固定ビットレートならOKだが固定品質だとNGとか
他のエンコーダなら固定品質でもOKだがTMPGEncだとNGといった確認が取れないと
TMPGEncの問題かどうか分からないと思います。

エンコーダ・オーサリングソフト・DVDプレーヤの相性って
結構あるような気がするのは私だけでしょうか。
これにメディアの相性が絡んできたりすると最悪ですね。

ご回答、ありがとうございます。

ちょっといろいろ試してみます

DVDit!のサポートFAQに、タイムコードが出ない問題が上がってます。
実際、問題ではなくオーサリング形式・設定でのDVDit!の仕様の様ですが。

それはそれとして。
見た目の現象としてタイムコードが出ないストリームは、DVD-Videoの規格できちんと
規定があります。
実際に、市販の映画等のDVDで、ローディング直後のメーカーロゴ部の再生中は
タイムコードが出ずにPLAY表示 ( 多くのDVDプレーヤでは ) で再生されるものが
多くありますし。
現在、個人が手を出せる価格帯のオーサリングソフトでは、ユーザーがこの辺りの設定を
自分で明確に指定可能な製品は私の知る限りなかったと思います。

aviutlにて出力したファイル
（解像度：640*480、フレームレート：29.97fps、サイズ：３６，７ＧＢ）
をTMPEGEncに読み込ませ、それをTMPEGEncで非圧縮aviで出力させたファイルを再生すると、
再生時間が３分を過ぎたあたり（計算してみると、大体ファイルサイズが４ＧＢをすぎたあたりでした。）
で急に画像が変な物になります。
「変な画像」と書きましたが、具体的には
　・画面が４分割される。
　・分割された画面ごとに、違う単色の色になる。（多分、それぞれRGBの原色だと思います。）
　・分割された動画の内容は、そのムービーの最初の部分。
また、音声をインターリーブして出力してみますと画像が変になったところから、ただのノイズが再生されます。

同じ解像度の色々なソースで試しましたが、全て同じような結果となりました。
また、様々な再生ソフトで再生しても同じでした。

TMPEGEncのバージョンは2.58、
ＯＳはＷｉｎｄｏｗｓ２０００　ＳＰ３、
動画の編集で使っているパーティションは全てＮＴＦＳでフォーマットした物です。

解決方法等ありましたらお教え下さい。
よろしくお願いします。

もっと、AVI とか、NTFS や FAT 毎の１ファイルあたりの容量などを
勉強してから来ませう。


４リットルペットボトルに３０リットル以上入らないのは何故？
と聞いてるようなものなので。

AVIは4GがMAX。

AviUtlで出力したソースファイルは正しく再生されるのですか？
しかし、このソース自体が無圧縮aviではないんですか？
それをさらにTMPGEncで無圧縮出力って何がしたいのでしょう。

PS.私には懇さんや船長さんのおっしゃっている意味がよくわかりません。
TMPEGEnc2.58・Win2000・NTFSなら4G超のaviファイルは作成可能だと思うのですが。

AviUtlが出力した36.7Gのファイルは正しく最後まで再生出来ますか？　またTMPGEncが
出力した正しく再生出来ないファイルをTMPGEncに再度読み込んだ場合、同じように映像
が乱れますか？

>しかし、このソース自体が無圧縮aviではないんですか？
>それをさらにTMPGEncで無圧縮出力って何がしたいのでしょう。

TMPGEncでしか使えない機能、aviutlでしか使えない機能を両方とも使いたいからです。
TMPGEncでさらに無圧縮出力する理由は、Windows Media Encoderにて
Windows Media Video形式に変換したいからです。


>AviUtlが出力した36.7Gのファイルは正しく最後まで再生出来ますか？

はい、出来ます。


>またTMPGEncが
>出力した正しく再生出来ないファイルをTMPGEncに再度読み込んだ場合、同じように映像
>が乱れますか？

試してみましたが、「ファイル "・・・.avi" は開けないか、サポートしていません.」というエラーメッセージが出ました。


ＴＭＰＧＥｎｃのバージョンを古い物に変えて試してみたり、
Ｗｉｎｄｏｗｓ２０００を追加でクリーンインストールして試してみたりしましたが、改善されませんでした。

>>またTMPGEncが
>>出力した正しく再生出来ないファイルをTMPGEncに再度読み込んだ場合、同じように映像
>>が乱れますか？
>
>試してみましたが、「ファイル "・・・.avi" は開けないか、サポートしていません.」というエラーメッセージが出ました。


失礼しました。テストのためにVFAPIプラグインの一部を無効にしたことを忘れていました。
しかし、そのおかげで新たなことがわかりました。
aviutlで出力した36.7GBのファイルはVFAPIプラグインの「AVI2(OpenDML) File Reader」のみを有効にするだけで開けるのに対して、TMPGEncが出力した正しく再生出来ないファイルの方は、それに加えて「AVI VFW compatibility Reader」も有効にしないと開けないことがわかりました。
これは何か関係があるのでしょうか？

> PS.私には懇さんや船長さんのおっしゃっている意味がよくわかりません。
VFW は 4GB までしか対応できてないのよ。
んだから、4GB 以上のファイルは変になってあたりまえと言うか、
やるべきことではない。


AviUtl は AVI2 の出力に対応していて、TMPGEnc は対応していない。
だから、AviUtl で出力した AVI は再生できる。

そう考えるのが普通かな？



AviUtl のプロジェクト保存されたものを扱えばいいと思ったのだが、それでは駄目なんですか？
確かに、少し重くはなるかもしれませんがひとまず回避できるかなぁと思ったり。

>TMPGEncでしか使えない機能、aviutlでしか使えない機能を両方とも使いたいからです。
>TMPGEncでさらに無圧縮出力する理由は、Windows Media Encoderにて
>Windows Media Video形式に変換したいからです。
なんとなく想像はしていたんですがやはりそうでしたか。

普通はプロジェクトファイルでやり取りをして
aviファイルを実際に出力することは少ないのですが
プロジェクトファイル経由では何か問題があるのでしょうか。
それとWindows Media EncoderってVFAPIConvファイルは読み込めませんでしたっけ。

しかし4Gの壁は謎ですね。

>VFW は 4GB までしか対応できてないのよ。
VFWは2Gまでだと思いますが。

>AviUtl は AVI2 の出力に対応していて、TMPGEnc は対応していない。
Ver2.55から対応しているはずです。

私もTMPEGEnc2.58・Win2000_SP3・NTFSで実験してみました。
約6Gの無圧縮aviを出力したらelectさんと全く同じ症状が出ました。
しかしhuffyuvで出力したら（約6G）問題なく最後まで再生できました。
もしかしたら無圧縮の時だけダメなのかもしれませんね。（バグかなぁ？）

私もTMPEGEnc2.58・WinXP_Pro.SP-1・NTFSで実験。
8Ｇ超、4分強のファイルでしたが、2分を超えたところ、
恐らく4Ｇを超えた辺りから、全く同様の症状が出ます。
やはりバグ？

但し、VFAPIプラグインについては、electさんのようには
なりませんでした。AVI2(OpenDML) File Readerのみで、
開けます。何故でしょう？

VFWについては、恥知らずさんが正しいですね。

ああ，同じ症状が出てる人が居るんですね。ウチだけじゃなかったんだ。
私も2.58を使ってAVIファイル出力をすると，無圧縮では同じ現象に遭遇しま
した。huffyuvだと一見解決できますが，途中にソース側にはないノイズだけ
のフレームが混入したりします。

出力するAVIファイルは無圧縮で20GB，huffyuvで10GBぐらいです。同じ素材で
尺を短くして小さいAVIファイルを作ると再現しません。

結局2.55に戻すと全て解決したので，今は2.55を使い続けています。
環境はWindows 2000 Pro SP3 ＋ NTFSです。

私には「プロジェクトファイル」という概念がなかったので、
今までは様々な編集ソフトで一つのファイルを編集するとき、
いちいちＨＤＤに無圧縮出力させて、そのファイルをまた編集する、という
かなりの手間をかけていたのですが、これからはその作業がとても楽になりそうです。
情報をくださった皆様、ありがとうございます。

しかし、やはりこの現象はバグなのでしょうか。
もしそうだとしたら、堀さんには改善をお願いします。

とりあえず確認しました。おそらくTMPGEnc側の問題でしょう。そのうちオフィシャル
からの回答があると思います。ただ、今はオーサリングのβを作るために頑張っている
でしょうから、少し待って上げてください。

>とりあえず確認しました。おそらくTMPGEnc側の問題でしょう。そのうちオフィシャル
>からの回答があると思います。ただ、今はオーサリングのβを作るために頑張っている
>でしょうから、少し待って上げてください。

　無圧縮の時だけダメなら、当座の回避策として無圧縮時はRAVIとかの参照型AVIにするのも手かと。
　RAVIなら本体AVIはAVI1.0だし、無圧縮AVIで総合計20Gとかのデータでも問題無く作れます。

　普通はtpr等のVFAPI経由が一番楽ですが、たまにVFAPIを複数経由したりすると映像出力動作が怪しくなることがあるのと、フィルタをかけて、ビットレート等のMPEG化設定だけ変えて何度も再エンコしているときは一度中間AVIを作った方がフィルタ処理時間が節約できるので。

お世話になります。ペガシス河村です。
ファイル容量が4GBオーバーのAVIファイルの不具合ですが
再現が出来ました。大変申し訳ありません。

次期バージョンで修正を行いますので、現状の回避策として
huffyuvなどのCodecを使って出力をして頂ければと思います。

次期バージョンはスケジュールの関係上11月中旬を予定しています。

今回の質問とは関係ないのですが宣伝です(笑)
現在弊社ではTMPGEncの発展に手伝っていただける人材を募集しています。
TMPGEncを理解していなくても構いませんので動画やPC関係に興味がある元気な人で
弊社に興味をもって頂ける方が、いらっしゃっいましたらお気軽にお問い合わせ下さい。

それではよろしくお願いします。

2.59が出たので試してみましたが，問題なく正常に処理できました。
ご対応ありがとうございました。

　今さらながらの質問かも知れませんが、過去ログ検索でもヒットしなかったので、教えてください。

　いつも、無圧縮AVI(352x240)でキャプチャーしたものをMPEG1(1.75Mbps〜2.5Mbps)にエンコード
していましたが、AVIのビデオ形式は気にしていませんでした。これまでキャプチャー時のビデオ形式
としてRGB24を選択していましたが、YUY2を試したところ、容量が少なく済みましたが、TMPGEncでエン
コードしたところ、色がにじんでしまいました。静止画でいえば、減色したような感じです。
　Google等で検索したところ、RGB24に比べて劣る形式でもなさそうなので、試しに、間にAviUtl
をかますと、にじみはなくなりました。見た目、RGB24と同等。

　これは、TMPGEncの特徴なのか、それとも、YUY2がRGB24に比べて劣る形式なのか違いを含めて教えて
ください。
　また、YUY2でも画質的に問題なければ、容量の少ないYUY2に移行しようかなとも思うのですが、
アドバイスもお願いします。

環境：WIN98、TMPGEncBeta12d、AviUtl0.98d、GleamingShot2.9、LogitecLVC-MG1

う〜ん、これってmsyuv.dllの問題とは違うのかなぁ。
それからTMPGEncのバージョンが恐ろしく古いのは何か理由があるのでしょうか？

　早速のレスありがとうございます。

> これってmsyuv.dllの問題とは違うのかなぁ。

　Googleで msyuv.dll を検索すると、

「huffyuv で YUY2 を使う場合 デフォルトで設定してある msyuv.dll では YUY2->RGB24(32) に
　変換する場合、一度16BitRGBに変換するらしく精度が落ちる」

というのがヒットしましたが、huffyuv は利用したことがありません。でもファイル容量節約には、使えそう
なので、あとで試してみたいと思います。

> それからTMPGEncのバージョンが恐ろしく古いのは何か理由があるのでしょうか？

　いえ、逆で、何の問題も起きないため、古いまま利用しています。過去の変更点にも、YUY2の無圧縮AVI
での不具合は該当がないようです。

>「huffyuv で YUY2 を使う場合 デフォルトで設定してある msyuv.dll では YUY2->RGB24(32) に
>　変換する場合、一度16BitRGBに変換するらしく精度が落ちる」
>
>というのがヒットしましたが、huffyuv は利用したことがありません。でもファイル容量節約には、使えそう
>なので、あとで試してみたいと思います。
huffyuvのマニュアルか何かに書いてあったのですが、huffyuv 2.1.1をインストールした後で、レジストリをいじって、msyuv.dllのところ(FOUR CC関連がずら〜とあるところだったかな)をすべてhuffyuv.dllに変えたら、16ビットうんぬんの問題が解決されるらしいです。regeditの検索でmsyuv.dllを指定して書き換えるので、ちと面倒かと。これを自動的にやってくれるソフトもあります。たまたまどこかで拾ってきました。自動的にhuffyuvのコーデックインストールとレジストリ書き換えやってくれます。

　huffyuvの詳しい情報ありがとうございます。

　レスを参考にさらに検索しました。で、次のような解釈に至りましたが、もし誤りがあれば訂正お願いします。

1.キャプチャーカードにより、YUY2、RGB等のカラーフォーマットの取り込みに違いがある。
2.LogitecLVC-MG1は、Bt848というチップを使用し、Bt8x8は、YUY2で取り込みを行う。
3.LVC-MG1はRGB24も選択できるが、取り込みはYUY2で行い、ドライバがRGB24に変換している。
4.TMPGEncとLVC-MG1のコンビでは、
(1)RGB24のAVIは、そのままエンコード、YUY2のAVIはRGB24に変換してエンコード。
(2)TMPGEncがYUY2をRGB24に変換するときに不具合が生じている。
(3)AviUtlを間に使用すると、AviUtlがRGB24変換を行い、不具合が起きない。
(4)RGB24取り込みでエンコードとYUY2取り込みでエンコードの違いは、RGB24変換をLVC-MG1のドライバが
　行うか、AviUtlが行うかの違い。
(5)(4)の結果について、双方の変換処理能力が同等と仮定すれば、結果も同じ。よって、見た目で気に
　ならなければ、気にしなくてもよい。
5.見た目チェックの結果は、「ぼやける(1)<(2)<(3)緻密」となり、これまでどおり、RGB24取り込みが
　良かったんですが、この結果は一般的でしょうか。(2)が最もきれいかなと思っていたんですが、(3)の
　方が緻密に見えます。ちなみに、RGB24で640x480はHDDの取り込みが間に合わず(コマ落ち)、利用不可能。

(1)352x240、YUY2 無圧縮AVI -> 352x240、MPEG1、2Mbps(TMPGEnc、AviUtl経由)
(2)640x480、YUY2 無圧縮AVI -> 352x240、MPEG1、2Mbps(TMPGEnc、AviUtl経由)
(3)352x240、RGB24無圧縮AVI -> 352x240、MPEG1、2Mbps(TMPGEnc単独)
　※TMPGEncの設定はすべて同じ、AviUtlは範囲設定のみ。

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

とりあえず、huffyuv2.1.1をインストール後、regeditでレジストリいじってから実際に試してみてはどうでしょう。
Windows 2000なら
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionDriver32
以下の
VIDC.*
にあるmsyuv.dllをすべてhuffyuv.dllに変更。
その他のOSでも検索でmsyuv.dllを探して書き換えればできると思います。

http://www.nnet.ne.jp/~hi6/lab/pixel/
に色空間の解説があります。

　huffyuv2.1.1の情報ありがとうございます。試しました。便利なので、長めのキャプチャ時には利用
したいと思います。紹介いただいたサイトで、カラーフォーマットも少し分かったように思います。

　で、見た目で確認すればいいと言われればそれまでなんですが、Bt8x8では、YUY2でも劣るフォーマット
ではないという解釈であっているのでしょうか。
　それと、「TMPGEncがYUY2をRGB24に変換するときに不具合が生じている。」というのも正しい解釈で
しょうか。
　この2点がうまく理解できていないのですが、御指摘、訂正があればお願いします。
--------------------------------------------------------
##先の書き込みを少し修正します。
　　誤　※TMPGEncの設定はすべて同じ、AviUtlは範囲設定のみ。
　　正　※TMPGEncの設定はすべて同じ、AviUtlは範囲設定、(2)はインターレス解除も。

>YUY2でも劣るフォーマットではないという解釈であっているのでしょうか。
>「TMPGEncがYUY2をRGB24に変換するときに不具合が生じている。」
>というのも正しい解釈でしょうか。
YUY2がRGB24に比べて劣ることはないと思います。断言は出来ませんが。
TMPGEnc・・・については私は違う考えを持っています。
と言うのはVFAPI経由でデータをやり取りする場合には
無条件でRGB24に変換されてしまいます。
私は手元にYUY2のデータがないので実験できませんが
YUY2のソースをAviUtlだけでDivXとかにエンコードした時には色がおかしくなりませんか？
YUY2データをmsyuv.dllがデコードする限りRGB16になってしまうと思うのですが。
（WinXPのmsyuv.dllはRGB24対応ですが）
上の考えは推測ですので間違っているかもしれません。

　レスありがとうございます。

> YUY2データをmsyuv.dllがデコードする限りRGB16になってしまう

　勘違いしていました。TMPGEnc、AviUtlそれぞれが独自に処理しているものと思っていました。ただ、
AviUtlを経由すると問題ないことから、AviUtlには何らかの機能があるのかなと思うのですが。
　で、huffyuv2.1.1のレスは、そのソフトの利用ではなく、msyuv.dllをhuffyuv.dllに置き換えること
が目的だったんですね。せっかくのレスを取り違えていました。ごめんなさい。

　ここで、新たな疑問があります。「msyuv.dllをhuffyuv.dllに置き換え」をした場合、無圧縮は選択
できなくなり、すべてhuffyuvによる圧縮になるのでしょうか。
　もし、そんな心配などなく、画質にも影響しないのであれば、思い切ってすべて置き換えてみようと思います。

> AviUtlだけでDivXとかにエンコードした時には色がおかしくなりませんか

　AviUtlは、TMPGEncの補助としてしか利用していない(作者の方ごめんなさい)ので、単独でエンコードに
利用したことがなく、未遭遇です。
　普段は、TMPGEncで高ビットレートVCD用MPEG1のエンコード、WME7.1でWMV8のエンコードという環境です。
DivXではなくWMV8を利用するのは、ほぼすべてのWinPCで利用可能な自動再生CDを作成可能だからです。

知識不足のため返答するのが心苦しいのですが責任上レスさせていただきます。
Aviutlがmsyuv.dllを使ってデコードしているか
独自にデコードしているかは知りません。ごめんなさい。
Aviutl単独での無圧縮出力で色が変わらなければ独自デコードかもしれません。

huffyuvに置き換えても無圧縮キャプチャは出来るはずです。
msyuvとhuffyuvの置き換えはデコード時の精度を
16bitから24bitに上げるために使われます。

>YUY2でも劣るフォーマットではないという解釈であっているのでしょうか。

　色情報的には劣るフォーマットのはずですよ、実運用上ではYUY2でも十分っぽいだけで。

　もりのみやこさんのサイトの「カラーフォーマットのナゾ」によると、YUY2はYUV422と同等で、NTSCのTV/ビデオ映像もYUV422らしい。
　TV／ビデオ映像を扱う分には色の解像度的にはYUV422あれば足りるっぽいし、MPEGはYUV420とかで更に色の解像度落ちるから、YUY2で最低限必要な色情報は管理できるってｋとに成る、はず。
　Bt8x8でビデオキャプチャする分にはYUY2で十分かも知れないけど、YUY2がYUV422と同等なら、YUV444やRGB24bitよりは絶対値では色の解像度が劣るのは間違いは無いです。

>YUY2がYUV422と同等なら、YUV444やRGB24bitよりは絶対値では
>色の解像度が劣るのは間違いは無いです。
理論的にはまったくおっしゃる通りです。
しかし現実問題としてビデオデジタイザチップを含めて
完全にYUV444やRGB24bitで内部処理されるキャプチャボードというのは
あまりないという事を前提に書いたまでです。

　分かり易いレスありがとうございます。

> huffyuvに置き換えても無圧縮キャプチャは出来るはずです。

　安心しました。ひとまず置き換えて、しばらく様子を見ることにします。

> Bt8x8でビデオキャプチャする分にはYUY2で十分かも知れない
> 完全にYUV444やRGB24bitで内部処理されるキャプチャボードというのはあまりない

　「Bt8x8では」という前提なので、これでこの件も安心です。
　まだ、一つのソースでしか見比べていませんが、なぜか、RGB24の方が緻密に見えるので、色々試し
ながら、使い分けも考えたいと思います。

----------------------------------------------------------------
　## RGB24では不可能だった640x480の無圧縮AVIキャプチャーですが、YUY2では可能だったので、これ
からは、これぞというソースに利用しようかとも思いましたが、エンコード時間が3倍ほどかかるのに、
見た目352x240の無圧縮RGB24よりくすんでいる感じがするので、今のところ、利用しない方向です。残念。
　エンコード時間が実時間の3倍強かかり、何度も実験するのには抵抗があるのであまり実験はできない
んですが、暇を見てまたいくつか実験はしてみたいとは思っています。

フレームレート設定の

29.97 ÷　X　＝ Y fps

のXの値は何を意味してるのですか？

例えば、X=2の場合、14.985fpsとしてエンコードされます。
このフレームレートは規格には存在しないレートなので、内部的には29.97fpsとして擬似的に実現しているようです。
TMPGEncの設定画面では、マウスカーソルを合わせてしばらくすると、ツールチップテキストにより簡単な説明が表示されます、一度ご覧になっては如何でしょう？

mpeg2(VOB)からmpeg1にエンコ中にランダムに"TMPGEnc.exeの*********アドレスで書き込み違反が起きました。"というエラーメッセージで止まってしまいます。********はランダムに変わります。何か対処法はありますか。
OS WINXP-PRO
CPU AthlonXP2000+
Mem 512
以前はすべて成功してました。あまり記憶がありませんが、XP-SP1を当ててからかな。

VOB の出所を書かないとレセウが付かない可能性大有。

MTV1000で作成したMPEG2ファイルを
TMPGEnc(2.58)でAVI出力すると
映像は正常なのですが音声が無音です。
AVIの指定は、
映像：DivX5.02
音声：MP3 56k 24Hz(デフォルト)
です。

今年の夏にVer2.57で、このパラメータで作成した時は
問題なく作成できたのですが、2.58にあげてからおかしくなりました。
現在はVerも2.57に戻しても症状は変わりません。

Ver2.58でのパラメータで直るものなのでしょうか？

最悪はOSから再構築すれば直るのでしょうが、
それは最終手段と考えております。

mpegツールでmpeg動画を結合させようと思うのですが、
「ファイルXXX.mpgは、他のファイルと互換がありません」
というメッセージが出て結合できません。
何がいけないのでしょうか？

すべてのファイルは
CD NTSC (MPEG-1 352x240 29.97fps CBR 1150kbps, Layer-2 44100Hz 224kbps)
で統一されています。

一度全てのファイルをエンコードし、
その後に結合した方がいいのでしょうか？

環境
PC :WIN2000
MEM:192M

よろしくお願いします。

そのMPEG1ファイルが何によって作られたのか分かりませんが、TMPGEncがエンコード
したモノではないのでしょう。MPEGツールはTMPGEncがエンコードしたファイル以外は
動作保証してないので、うまくいかないのではないかと思います。

MPEGツールで結合処理を行ないたいなら、一度TMPGEncで再エンコードさせるのが良い
とは思います。しかしそうすると画質の劣化しますので、その辺りは考慮下さい。

とりあえずMPEGツールで読みこめるなら、簡易多重化でそれぞれをremuxしてはどうでしょうか。上手く行けばTMPGEncが作成したファイルという事になるので結合できるようになるかもしれません。もちろん結合しようとするMPEGファイルの解像度、フレームレート、音声、音声の周波数、音声のビットレートが同じでないと駄目ですが。

MPEGツールの「結合（カット）」で、「修正」をクリックすると
リストから消えるんですよね？
一度、フリーソフトのVCD Checkerで各ファイルを確かめてみた
ら如何でしょう。案外、アスペクト比が違うものがあったり、
パックサイズが狂っていたりするかも知れません。
他と異なるファイルがあれば、仮に簡易多重化することによって
MPEGツールで結合できたとしても、最終的におかしな動画となる
可能性があります。
やはり、fayさんが言われるように、再エンコードするのがベス
トだと思いますよ。

訂正させて頂きます。
フレームサイズ等の致命的な相違がないならば、ICZさんの言われる
ように、簡易多重化を試み、結合できればそれがベストです。
再エンコードは最後の手段です。
ファイルの状態によっては、VCD Checkerで情報書換し、無理やり結
合する事もできますが、「おかしな動画」となる場合があります。

私は、正常なMPEG1ファイルを、フリーソフトで結合させたらパック
サイズが異常な数値になってしまった事がありました。
この場合、最終的には再エンコードさせるしかありませんでした。

はじめまして。
さっそく質問なんですが、mpgファイルを再エンコするためにTMPGEncに読み込もうと、
ファイルを指定して開くとそのまま応答がなくなってしまいます。
読み込めるmpgファイルもあるのですが、何故か一部のmpgファイルをよみこむと
TMPGEncだけがかたまってしまいます。
拡張子も偽装されてません。
何か原因があるのでしょうか？もしわかるかたがいましたら、
よろしくおねがいします<(_ _)>

No.6161はご覧になりましたか?

過去ログ読んだら原因がわかりました。
すさんありがとうございました。
（過去ログチェックしてませんでした。探してきてくれて本当にありがとうございました<(_ _)>）

メイン画面に「エンコード終了後、シャットダウンする」がでないのですが？

No.5647はお読みになりましたか？

ありがとうございます。
助かりました。