全30件 (30件中 1-30件目)
1
vei-codec.iniの読み込み、fourcc->コーデック名称の処理を、一から書き換えています。もう、iniファイル読み込みの方法から、全く別の方法を採ることにしました。解析処理をするモジュール内で、読み込みと解放をすることにしたので、今までの方法だと、最善の方法ではなくなったからです。とにかく、今、書き換えの最中。
2007年01月31日
コメント(0)
特定のwavで、エラーも発生せず落ちる事が判明して以来、次QTにしようかな?とか、そういう事は、すべてストップしています。現在分かっていることは、vei-codec.iniがない時は、C無0001で、他も解析結果が出るVCLありのプロジェクトでコンパイルしたvei.dllでは、何も問題がないwav解析モジュール単体では、正常に解析される(DLLに実装するとダメ)といったところ。正直な所、何が原因なのか、全く、サッパリ分かりません。こりゃ、参った。ちょっと、デバグの手法を変えないと、トレースがしづらい状況なので、しばらく、バグ探しに時間を割きます。コーデック処理周りなのは、だいたい分かりかけてはいるけど、それだけでは、範囲が広すぎます。
2007年01月30日
コメント(0)
http://yakki-.hp.infoseek.co.jp/tc/videoeasyinfo/vei070129a.lzhようやく、公開の目途が立ちましたので、ブログ限定で公開します。ドキュメントは付けていません。veimain.exeを実行してください。・β以前のα版ですので、二次配布は禁止とします。・Delphi版のveiとは、070128βと入れ替えて使用することはできますが、できれば、同梱のveimain.exeから使用・実行してください。現在、解析できるのは、動画は、mpg,avi音声は、wav,mp3,ac3,dtsです。おそらく、まだまだ、うまく解析ができないファイルとか、強制終了するケースが多々あると思いますが、報告があれば、対処するつもりです。さて、次に、QTにいくか、matroskaにいくか、気分的には五分五分ですが、明日、また、決めます。
2007年01月29日
コメント(4)
C版でメモリーの確保/解放の問題に取り込んでいるうちに、Delphi版の方に、同様の問題があることが判明し、それの修正をしました。それに伴いDLLの仕様を更に変更しました。まだ、この先も、仕様がどうなるか分からない所もあるので、まだβは取れません。実のところ、本当に、メモリーの解放が行われていなくて、メモリーリークが起きているのか、確認しておりません。どう、確認したらいいのかすら分かっていない。少なくとも、DLL内で、確保した領域を、解放している部分が存在しないので、実際はどうであれ、プログラムでは、キチンと解放するようにしました。ということで、C版の方ですが、Delphiと同じような処理を書くと、例外エラーが発生するので、コーデックの読み込み自体の方法を変えました。※そもそもメモリーの解放し忘れというのは、コーデック変換のあのファイルを読み込んだまま、解放していなかったいうことです。コーデック名称への変換が必要な、wav,aviについては、すでにプログラムを修正しました。本当に、もう、近日、サンプルの公開をしたいと、思ってはいます。
2007年01月28日
コメント(0)
これまで、コーデックファイルは、動的に(malloc,free)確保してきました。その解放をし忘れていたので、freeをする関数を作り、実装したところ、例外エラーが出ることがあり、try~catchで食い止めようとしたものの、何だか、うまくエラーを捉えてくれないようなので、コーデックの読み込みのタイミングを変える事を検討しています。そういう事で、また、サンプルの公開は、少し先延ばしになります。Delphi版の方は、エラーの発生は大丈夫そうなので、別途考えます。なかなかね、どういう手法を採ればいいのか、試行錯誤の連続です。
2007年01月27日
コメント(0)
ファイル名を取り出す方法として、_splitpathというライブラリを使う方法で、うまく行ったので、これで通します。現在、DLLの方は、デバグのために、VCL使用プロジェクトで作っています。これだと、250KB強。VCLなしでもプロジェクトを作ってあって、こちらだと、170KB強。公開する時は、VCLなしでコンパイルします。最終的には、200KBちょっとくらいのサイズになるのを目標としています。この2~3日、あれこれありましたが、何とか、乗り切れた感があります。あ~、でも、まだ、これからなんでしょうね。とにかく、ここまで来た以上、現状のvei.dllに追いつけるように、何とかする以外にないと思っています。ここまで来て、挫折はしたくない。
2007年01月26日
コメント(0)
フルパスから、ファイル名を取り出せなくて、昨日は、あれこれいじっていて、いじりすぎて、ファイル名がおかしくなったことをブログで書きました。昨日の追記以降も、とりあえず、共有フォルダは無視して、ローカルドライブのファイルを正しく表示できるように、もともとの関数に戻しました。今日、昨日のソースのまま、とりあえず、コンパイルしてみたら、何だか知らないけど、共有フォルダのファイル名がおかしくなるのが直っていました。ちゃんと、ファイル名のみが取り出せる形になっています。ということで、足踏み状態からは脱した模様。もう、これからは、毎日のバックアップ(LZHで固める)を、その日の終わりに実行することにします。いくつか、サンプルファイルを解析してみて、音声がおかしいのが見つかったので、その都度、細かな調整をしているところです。ちょっと、話は変わりますが、C版では、vei-codec.iniを、mallocで動的に確保しているのですが、そうすると、解放する必要が生じます。ということで、終了処理を行うDLL側の関数が必要になるので、DLL仕様を、また、修正(追加)する必要が出てきます。そういえば、現Delphiも、Tstringlist使っているから、本当は必要なはず。あれ?これは、ちょっと確認しないと。今のところ、メモリーリークしているっていう報告はないけど、ちょっと、心配。今作っているDLLと呼び出し側の実行ファイルのブログ限定での公開、延ばしたままになっています。AVIが片付いたら、公開しようと思っていますが、さて、どう転ぶか?
2007年01月25日
コメント(0)
編集ソフト名を片付けて、結果表示を整えました。AVI2.0 640x480 24Bit 29.970fps 6254f 3421.894kbps [Windows Media Video 9] [wmv3/WMV3](-1)MPEG1 LayerIII 48000Hz [CBR Joint Stereo /MS] 320.00kbps [LAME3.93 CBR] [960bpf/8697f]VirtualDubMod 1.5.10.1 (build 2389/release) VirtualDubMod build 2389/release33367μs/f (2997/100)(Flag) [I/L(1)] [RIFF] 97,816,576Byte 0:03:28.675(208.675342sec)DLL 070114α[*.avi]AVI2.0 640x480 24Bit Windows Media Video 9 29.97fps 6254f 3421.89kb/sMPEG1-LayerIII 48.00kHz 320.00kb/s CBR JointStereo/MS LAME-Info 8697f [LAME3.93 CBR 320kb/s JointStereo][RIFF] 00:03:29 (208.68sec) / 97,816,576Bytes真空波動研SuperLite 070101 / DLL 070101まだ、デバグ用の文字が散らばっていますが、必要な情報は、ほぼ拾えました。さて、これまでは、あまり、意識していませんでしたが、2台のPCをLANでつなげていて、共有フォルダに、ビデオファイルをためているので、共有フォルダ経由で解析をさせるとどうなるか?といくつか試しています。いくつかのファイルで、ファイル名の取り出しがうまくいかないみたいで、文字化け?に似た症状が出ています。VCL(ExtractFileName)を使えば、一気に解決なんですが、今回、そういう便利な関数は使わずに行きたいので、Win32 APIか、Cのライブラリで、何とか切り抜けたいのです。例えば、_splitpathなんていう、ファイルパスを分解するライブラリを、googleで見つけたのですが、どうも、DOSコンソールと、Win32で挙動が違うんです。DOSでは、問題ないのに、構造体経由にすると、何だか変。ちょっと、これは、追究する必要あり。AVIがすんだら、QTに行くか、matroskaに行くか、ちょっとだけ、一息(休憩)付くか、考えます。追記22:39ファイル名を取り出せない不具合を修正しようと、色々いじっているうちに、何だか、とんでもない事態に、はまってしまいました。ファイル名を保存している領域が何らかの原因で壊されてしまっているようです。解析結果のファイル名が明らかに、おかしい。ちょっと、2~3日足踏み状態になるかも。DLL開発は、何とか、前進したいものの、事態が変わらない場合は、ちょっと、冷却期間を置くことも・・・orz。
2007年01月24日
コメント(0)
昨日まで、MP3,AC3とできあがり、DTSも解析できるようにしました。AVI2.0 592x320 24Bit 23.976fps 3737f -1145.209kbps [XviD 1.1.0 Beta2] [xvid/XVID](0)0 AC3 48000Hz 5.1 Ch(3/2) L/C/R/SL/SR CM 448kbps1 DTS-ES(XCh) 48000Hz 5.1Ch C+L+R+SL+SR 24Bit 768.00kbps[*.avi]AVI2.0 592x320 24Bit XviD 1.1.0 Beta2 23.98fps 3737f -1145.20kb/s[Audio][2]Dolby AC-3 48.00kHz 5.1ch(3/2 L+C+R+SL+SR+LFE) CM 448.00kb/sDTS-ES(16BitBE) 48.00kHz 24Bit 5.1ch(C+L+R+SL+SR+LFE:XCh) 768.00kb/s[RIFF] 00:02:36 (155.86sec) / 1,048,576Bytes真空波動研 070101 / DLL 070101また、PCMのビットレートがおかしかったのも、気になっていましたが、単に、ulongなのを、ushortで読んでたという初歩的なバグでした。AVI2.0 640x480 16Bit 29.970fps 12076f 1179.455kbps [XviD 1.0.3] [xvid/XVID](0)0 PCM 48000Hz 2Ch 1536.000kbps (0x3814)1 MPEG1 LayerIII 48000Hz [CBR Joint Stereo /MS] 128.00kbps [384bpf]まだ、完成された解析結果を出すまで至っていないので、若干、結果の順番がアレですが、もう少ししたら、ちゃんとした形式に生成できるでしょう。後は、編集ソフト(ISFT)を取り出せれば、必要な情報の取得はOKでしょう。そうそう、これで終わると、タイトルの主題を書き損ねる所だ。初めから、マルチストリーム対応を念頭に置いたり、AVIの場合で、特に、VBR絡みだと、詳細取得が失敗したら、標準形式の表示 or ビットレートやCBR/VBRのみの書き換え等、音声情報の項目を各ストリーム毎に、また、標準、詳細それぞれに持っていないと、とんだことになってしまいます。Delphi版では、後から、マルチストリーム対応を図ったので、音声情報の持ち方が非常にややこしくなってしまった。そういう反省を踏まえて、構造体を使ったり、配列を多用したりと、工夫をしているつもりです。そういうあたりは、video easy infoのこだわりとします。
2007年01月23日
コメント(0)
このブログを定期的に見に来ている人から見ると、何だかものすごい勢いで、C版vei.dllの開発を進めているように読み取れるでしょう。無論、可能な限りのプライベートな時間をすべて注ぎ込んでいます。気持ちの中では、速いところ、現状のDLLに近づけて、Delphi版とC版を交代させたい所です。そういう成果を早いところ出したい。そんな所です。まだ、C言語の再挑戦を決意して、3ヶ月ちょっとなのに、もう、ものすごい技法をいろいろ試しています。何をこんなに焦っているんでしょう?この先、このブログ上で、少しずつ、その答えが分かってくるかもしれません。さて、AVIの音声の中で、MP3,AC3,DTSについては、詳細解析をすることは、変わっていないので、今、順に着手しています。おおまかには、いいのですが、やはり、100%じゃありません。今は、過去に、veiの機能テストに使っていたファイルを解析させて、ひとつずつバグを潰す。そういう事の繰り返しです。まだですね、ポインタの扱いが危なっかしぃところがあります。コンパイラではエラーを吐かないのに、解析結果がちょっと変だったりして。とにかく、まぁ、AVIが成功すれば、oggも、matroskaも、さほど困難ではないと考えています。後に手を出す形式のためにも、このAVIは、キッチリと結果を出していきたい。なんで、こうも、必死なんだろう。そういうことへの答えも、そのうち書けるようになるだろうか?
2007年01月22日
コメント(0)
RIFF チャンクのチェイン解析が、まだ、不十分であったことが判明したので、再度、練り直した。どうも、チャンクサイズが0のものが出てきて、そこで、ちゃんと、次のチャンクに飛べなかった。今の所は、何とか、うまく動いているけど、まだ、色々試してみないといけないなぁ。[*.avi]AVI2.0 640x480 16Bit XviD 1.1.0 Final 29.97fps 234659f 1499.06kb/sDolby AC-3 48.00kHz 2.0ch(2/0 L+R) CM 192.00kb/s[RIFF] 02:10:30 (7829.80sec) / 1,655,162,352Bytes真空波動研SuperLite 070101 / DLL 070101AVI2.0(2) 640x480 16Bit 29.970fps 234659f [XviD 1.1.0 Final] [xvid/XVID](0)Dolby AC-3 48000Hz 2Ch 192.000kbps (0x1000c)playtime 7829.796455AVI2.0 640x480 16Bit 29.970fps 12076f [XviD 1.0.3] [xvid/XVID](0)0 PCM 48000Hz 2Ch 487.424kbps (0x380c)1 MPEG1-LayerIII 48000Hz 2Ch 128.000kbps (0x1af14)playtime 402.936270[.avi]AVI2.0 640x480 16Bit XviD 1.0.3 29.97fps 12076f 1179.46kb/s[Audio][2]PCM 48.00kHz 16Bit 2ch 1536.00kb/sMPEG1-LayerIII 48.00kHz 128.00kb/s CBR JointStereo/MS[RIFF] 00:06:43 (402.94sec) / 1,048,576Bytes真空波動研SuperLite 070101 / DLL 070101ご覧の通り、ビデオ情報の詳細(DivX,XviD)取得は、うまく行っていそう。明日以降、オーディオ情報の詳細に踏み込む。
2007年01月21日
コメント(0)
今朝から、AVI解析に取りかかっています。音声のマルチストリームと、とりあえず、標準形式での表示と、詳細解析のとっかかりも含めて進めています。まだ、ブログに成果を載せるまでに至っていませんが、まずまずなところまで来ています。このAVIがある程度出来てしまえば、oggにしろ、matroskaにしろ、情報の保存位置から詳細を出す道筋はできるはず。MPEGができあがった時点でのサンプルの公開を、ずっと、考えてきましたが、まだ、このAVIが問題のない状態になるまで、待たないといけなくなりそうです。
2007年01月20日
コメント(0)
Quick Timeのatom構造の解析は、何とかできたので、このコードをちょっと変更すれば、AVIのRIFFチェインの解析もできるんじゃないかと、AVIの中を見ながら、やってみました。12 0x2284(8836) LIST (0)20 0x68697661(1751742049) hdrl (1)24 0x38(56) avih (2)88 0x109a(4250) LIST (3)96 0x68727473(1752331379) strl (4)100 0x38(56) strh (5)164 0x2e(46) strf (6)218 0x1018(4120) JUNK (7)4346 0x108a(4234) LIST (8)4354 0x68727473(1752331379) strl (9)4358 0x38(56) strh (10)4422 0x1e(30) strf (11)4460 0x1018(4120) JUNK (12)8588 0x104(260) LIST (13)8596 0x686c6d64(1751936356) odml (14)8600 0xf8(248) dmlh (15)8856 0x38(56) LIST (16)8864 0x54465349(1413894985) INFO (17)8868 0x2c(44) ISFT (18)8920 0x520(1312) JUNK (19)10240 0x5d15620(97605152) LIST (20)10248 0x62773130(1651978544) movi (21)10252 0x4ec0(20160) 01wb (22)30420 0x9dfd(40445) 00dc (23)70874 0x780(1920) 01wb (24)72802 0x1027(4135) 00dc (25)お見事!今まで、力業でmoviチャンクを探していたのに比べたら、ちゃんとRIFFのルールに則ってやる方が、いいに決まっています。インターリーブ判定も、ここまでリストアップされていれば、問題はないと思います。この週末に、一気に、AVIを攻略できたら・・・いいな。
2007年01月19日
コメント(0)
隙間その1mallocで、動的に配列を確保する手法は、随分慣れたが、free...解放することを忘れているモジュールが多数見つかった。一応、return 0; つまり正常終了する場合は、その直前に、freeで解放させるようにしたが、はて、途中で異常終了する時も、freeを入れないといけないか。やっぱり、ご丁寧にfreeは必要かな?隙間その2Quick Timeのatom走査は、ほぼ問題なさそう。で、昨日のサンプルのような結果まではいいのだが、それを、DLLに実装してエラーが出ないか確認しないと本当に安心はできない。[*.mov][15]0 0x27f78(163704) /moov (0) 0Byte 0:00:00.000(0.000000sec)DLL 070114α----------まぁ一応、昨日とは、違うファイルで、一つめのatomを持ってこれた。これで、通常の解析をさせれば大丈夫だろう。で、よくよく考えてみると、今回、再帰処理でatomを走査しているので、最初っから、atomがファイルの頭から順番に並んでいる。それなら、atom走査と、そのatomの解析を同時に進めてもいいような気もしなくはない。とすると、いちいちリスト構造に取り入れなくても、いいような気もする。ま、これは、実際に解析コードに手を出した時に考えよう。隙間その3DLLの方は、一応、Cコンパイラに依存しないでコードを書いているつもりですが、本当に依存していないか、確認するには、VS2005のVisual C++でコンパイルできるのか確認するのが、一つの手。それで、VC++を入れて見たんだが、かってがまるで違う。VC++でwin32アプリを作るには、SDKが必要なようで、それも入れた。一応、普通のWindows(Form)は表示されたが、それだけ。もう、頭の中は、BorlandのIDEしか認識しなくなっている。MSは、無償でVisual Studio 2005 Expressを公開していますが、結局、私にとっては、無用の長物なのか?まぁ、Borlandの開発言語で、ソフトが作れればいいんです。QuickTimeは、簡単なビデオ情報を取得させてみて、それが問題ないレベルなら、保留にして、AVIに移る&MPEGまでのサンプルを公開(したい)予定。
2007年01月18日
コメント(0)
リスト構造の方が、大方、うまく行っているようなので、atom走査をDelphiからCに移植することにしました。この手のものは、再帰処理が書ければ、そんな手間にはなりません。Delphiで書いた時は、そういう効率は除外し、とりあえず動くことを優先したため、擬似的な再帰処理を書いていました。今回、Cだったら、完全に再帰処理ができる言語ですから、ちょっと、再帰に挑戦。元々のコードにちょっと手を加えたら、苦労なく動いた。0 0x1c(28) /ftyp 28 0xe9e2(59874) /moov 36 0x6c(108) /moov/mvhd 144 0x12(18) /moov/drm 162 0x6d67(28007) /moov/trak 170 0x5c(92) /moov/trak/tkhd 262 0x24(36) /moov/trak/edts 270 0x1c(28) /moov/trak/edts/elst 298 0x6cdf(27871) /moov/trak/mdia 306 0x20(32) /moov/trak/mdia/mdhd 338 0x3a(58) /moov/trak/mdia/hdlr 396 0x6c7d(27773) /moov/trak/mdia/minf 404 0x14(20) /moov/trak/mdia/minf/vmhd 424 0x24(36) /moov/trak/mdia/minf/dinf 432 0x1c(28) /moov/trak/mdia/minf/dinf/dref 460 0x6c3d(27709) /moov/trak/mdia/minf/stbl 468 0xa9(169) /moov/trak/mdia/minf/stbl/stsd 637 0x18(24) /moov/trak/mdia/minf/stbl/stts 661 0x5a8(1448) /moov/trak/mdia/minf/stbl/stss 2109 0x1948(6472) /moov/trak/mdia/minf/stbl/stsc 8581 0x3c54(15444) /moov/trak/mdia/minf/stbl/stsz 24025 0x1030(4144) /moov/trak/mdia/minf/stbl/stco 28169 0x7bf5(31733) /moov/trak 28177 0x5c(92) /moov/trak/tkhd 28269 0x24(36) /moov/trak/edts 28277 0x1c(28) /moov/trak/edts/elst 28305 0x7b6d(31597) /moov/trak/mdia 28313 0x20(32) /moov/trak/mdia/mdhd 28345 0x3a(58) /moov/trak/mdia/hdlr 28403 0x7b0b(31499) /moov/trak/mdia/minf 28411 0x10(16) /moov/trak/mdia/minf/smhd 28427 0x24(36) /moov/trak/mdia/minf/dinf 28435 0x1c(28) /moov/trak/mdia/minf/dinf/dref 28463 0x7acf(31439) /moov/trak/mdia/minf/stbl 28471 0x5b(91) /moov/trak/mdia/minf/stbl/stsd 28562 0x18(24) /moov/trak/mdia/minf/stbl/stts 28586 0x2df4(11764) /moov/trak/mdia/minf/stbl/stsc 40350 0x3ccc(15564) /moov/trak/mdia/minf/stbl/stsz 55914 0xf94(3988) /moov/trak/mdia/minf/stbl/stco 59902 0x8(8) /free 59910 0x8(8) /free 59918 0xdad956(14342486) /mdat 何だか、こういう具体的な成果を書くのは、久しぶり。これを、リスト構造経由で、配列に取り込めれば、QTの解析は、半分できたも同然。QTを保留したまま、AVIに踏み込めるはず。
2007年01月17日
コメント(1)
リスト構造については、googleで探せば、それなりのサンプルや解説を集めることができる。一(単)方向については、データと、次の構造体へのポインタで構成していれば、問題ないらしい。一応、タイトルで示すようなデータの流れのサンプルは、できた。鍵は、mallocで一つ一つの構造体の確保をすることと、次の構造体へ、今の構造体のアドレスを渡すことだけ間違わなければ、さほど難しくはなさそうだ。それと、mallocで確保したメモリは、freeで必ず解放しなければならないという点。これって、今までの解析プログラムで、もしかすると、freeで解放をし忘れている箇所がありそう。とにかく、Cってメモリ管理は、すべて、プログラマー任せなので、その辺を忘れると、いわゆるメモリーリークの原因になってしまいそう。もう少し、複雑なサンプルがちゃんと動くようになったら、QTのatomチャンクの走査に手を出してみようと思う。ここまでの解析のサンプルを公開するのも、予定のまま来ていますが、今やっているリスト構造の見通しが付けば、ちょっと考えます。
2007年01月16日
コメント(0)
MPEGの場合、ファイルの最後が破損していると、再生時間の取得に関わるので、うまくスキップさせないといけないのです。veiでは、そうしているので、そういう処理を加えました。これに関しては、すでに、EOF Deluxeで、関数を作ってあるので、それを、#includeするだけです。さて、Tstringlistの代替えで、一番ネックになりそうなのは、動的にリストの内容の個数を増やすことが容易いシステムを実現しないといけないことです。で、思いついたのが、リスト構造、これって、基本情報の試験の時に、なんかよく扱われた内容で、構造体を使って動的に項目を増やせる手法です。QuikTimeなら、atomチャンクが見つかる度に、リストに追加し、すべてのatomを走査したら、その個数を調べ、改めて、構造体の配列に入れ直すというのを考えています。それが、時間が掛からないで済む方法なのかは実際にプログラムを作ってみないと分かりませんが、さて、どうなることやら。とにかく、一度、リストの個数が分かってしまえば、自分の十分理解している方法に持ち込めると思う。ということで、AVIの解析に手を付けたい所ですが、QTを先にやることになりそうな・・・。
2007年01月15日
コメント(0)
MP3などの、タグを付けられる形式については、どんなタグが付いているのか、調べるようにしています。普通は、そういうタグの情報と実際のデータの間に、パッディングされた領域は、ないものとして解析処理を書いていますが、中には、タグ情報と、実際のデータの間に、00データが挟まっている場合もあり、そういう場合は、スキップしないといけなかったりします。そういう場合の結果表示の形式も、今回、C版vei.dllを作る上で、決めてしまった方がいいと考えています。タイトルの通り、この先の事態に備えて、解析対象のファイルが何か?というチェック自体を、前もって実装させようと、現状のvei.dllで解析可能な形式のものについは、形式のチェックを先に実装させました。そうしてしまえば、後は、実際の解析処理コードを#includeで実装してしまえば、即、実際の解析ができるようになります。今の所は、MPEG,AC3,DTS,MP2(3),WAV,RIFF MP3の解析が、ほぼ問題なさそうな所に来ました。近日、ここまでのサンプルを、このブログ上で、公開する予定です。次は、AVIの予定で、いるんですが、場合によっては、Quick Timeを先に済ませてしまうこともありえます。というのも、今回、Cで書き直す上で、VCLを使わないようにすることを目標にしています。Delphiでは、解析の中で、Tstringlistを使っていて、このTstringlistがVCLなので、何か使わずに済む回避手段があるか、見つけないといけないのです。一応、大まかな代替え処理手法のアイディアがあるので、それを具体化できるかどうかが鍵となります。この頑張りが花開く時を信じて...
2007年01月14日
コメント(0)
今日は、お休みということで、1. Turbo C++を、メインPCに入れ直した今まではメインPCにDelphi,サブにTurbo C++を入れていましたが、入れ替えました。Turbo C++にも、bcc32(コマンドライン用コンパイラ)があることが分かり、結局、BCC++5.5は、使わなくなりそうです。CPUの速さから言うと、サブ>メインで、コンパイル時間は掛かるようになったのですが、まぁ、そんな劇的に遅くなる範疇ではないので、いいとしよう。2.RIFF MP3の解析着手単なるMP3は、もうOKですが、RIFFコンテナに格納されたMP3も、今の段階でやっておく必要があるので、手を付けました。それにしても、自作のファイル操作関数に、ちょっと、難が見つかってしまった。どうも、FILE_CURRENT時のシークが怪しい...orz今は、FILE_BEGINで、代用しているが、直せるものなら、直しておきたい。後は、コンパイルで生成されるDLLファイルのサイズ。これが、予想以上に大きくなってしまい、その原因を探る必要性がありそう。一応、AVIに手を出す前に、一度、このブログ経由で、公開する予定。
2007年01月13日
コメント(0)
VCLのstringlistを使うつもりで、実際にどうプログラムを組もうか、色々考えてみましたが、どうも、いいアイディアが浮かばずに、以前作ってあった、テキストファイルをバイナリから読み込むソースを、いじっていました。これは、そこそこ良いところまで作ったあったものですが、セクションとfourccを指定したら、コーデック名称を返す関数を作りかけで保留にしていました。stringlistが、ちょっと、うまく使いこなせそうにないので、だったら、保留のものを、もう一度再開してみようかと、やってみました。一応、形にはなりましたが、Setpathでのパス指定込みのiniファイルの指定が、ちょっとうまく行っていない。これが、うまく行けば、一気に、コーデック名称の変換をする処理は、カタが付く。結局、これでいければ、BCCでの開発のままいけるので、いい方向に向かいそうだ。別件で、Turbo C++のインストールフォルダを見てみたら、bcc32.exeがあるんですね。な~んだ、TC++を入れさえすれば、コマンドラインのコンパイルも出来るって事なんですね。気付かなかった。
2007年01月12日
コメント(0)
引き続き、MPEGの解析を進めています。次に、AVIの解析に手を出す予定ですが、MPEG系にはなかった、Fourccのコーデック名称への変換をしないといけなくなります。それには、vei-codec.iniを読み込まないといけないわけですが、Tstringlistを使うつもりでいます。もちろん、これは、VCLの一機能なので、BCCでは使えません。こればかりは、TC++で組まないといけないのです。これまで、BCCとTC++は、別PCに入れてLAN経由でファイルを転送し、DLLへの実装を行ってきましたが、そろそろ、それも限界。やはり、BCCとTC++を同一PCに入れてやらないと、何とも効率が悪くなってきました。そうすると、今度は、TC++とTDelphiが共存できないので、つまりは、Turbo DelphiとC++を入れ替えることが必要になります。週末に、そんな作業を、決行しようかな・・・。
2007年01月11日
コメント(0)
[*.mpg][17]720x480 4:3 9000kbps 29.97fpsMPEG1 LayerII 48000Hz [CBR Stereo] 384.00kbps [1152bpf](30000/1001)fps[T] delay -66.644444ms[MPEG2] 33,525,696Byte 0:00:38.984(38.984778sec)DLL 070103α[*.mpg][13]352x240 4:3(NTSC) 1150kbps 29.97fpsMPEG1 LayerII 44100Hz [CBR Stereo] 224.00kbps [731bpf]encoded by TMPGEnc (ver. 2.524.63.181)(30000/1001)fps[B] delay 0.000000ms[MPEG1] 4,234,328Byte 0:00:24.280(24.280000sec)DLL 070103αこれは、Cで作り直しているvei.dllでの解析結果です。TFFも、DELAYも、編集ソフト名も、何とか取り出しに成功しています。まだ、詰めの甘い部分もありますが、おおまかには、完成に近づいています。それにしても、キャストや、演算など、まだまだ、Cの文法が理解しきっていないので、なかなかツライところがあります。
2007年01月10日
コメント(0)
昨日書いた通り、MPEG2固有の情報,TFF(Top Field First),MPEG AUDIOのDELAYなど、真空では取得していない情報の取得に取りかかっています。すでに、Delphiで書いてあるコードをCに書き換えるだけなんですが、MP3の時は、かなり手こずりましたが、今日は、結構、楽に書き換えができました。MP3系で、残っているのが、RIFFコンテナに格納されている、いわゆるWAVEヘッダ付きのMP3でして、これが、また、ちょっと、手強いかもしれません。MPEG系では、TSを最後に回す予定で、他のものは、これまででほぼ終わっています。近いうちに、MPEG系のみ解析可のvei.dllをブログ上限定で公開しようかなと、そんな事を考えています。今まで、C言語の文法で、{} で括る形式が、どうにもしっくり来ない時期がありました。Delphiのように、begin~endの方が、見た目でしっかりしていて・・・。でも、最近は、{}で括る形式の方が、見やすいかなと思うようになりました。C言語に再挑戦を始めて4ヶ月、今更ですが、やっぱり、プログラミングにおいて、C言語は、避けて通れないとつくづく思います。うまく書けないけど、実行環境の自由度から言うと、Delphiでは、足下にも及びませんね。
2007年01月09日
コメント(0)
昨日に引き続き、MP3の解析を進めています。要は、MP3のヘッダ(4バイト)だけでは、CBR/VBRの区別すらできないので、LAME等のエンコーダ名の取得を含めて、ヘッダの4バイト以外データを読み取るって事です。この作業は、Delphiですでに書いている内容を、単純にCで書き直す事になるわけですが、それが単純にはいかないのも、苦労する一因です。すでに、一応、終了しています。次は、MPEG2のTFF,DELAY値だな。それが終われば、一応、MPEG系は済むはず。
2007年01月08日
コメント(0)
正式版で公開するつもりでいたのですが、公開間際になり、やたらと、バグが見つかり、こりゃ、βで様子を見た方が良さそうだと判断して、β公開にしました。もう、なんだか、多機能にしていった歪みが今頃になって出てきた感じです。もう少し、冷静に対応できるようにしたい所ですが、ちょっと、焦りもあります。C版vei.dllは、今、MP3の詳細(LAME等)の解析に手を出しています。MPEGの方は、MP3が済んでからでしょうかね。
2007年01月07日
コメント(2)
vei.dllの仕様の変更内容は、問題ない。それで、新仕様に即した、videoei.exeとmini版を公開するべく、修正&テストをしていたら、何か、今まで、気付かなかったバグが、次々に出てきて、それを修正しようとしていたら、ファイル形式判定処理に支障が出て来て、結果的には、何とかなりましたけど、かなり、もう、現ソースに、限界が近づいてきているって事なんでしょう。やはり、もう、これ以上、veiのDLLをDelphiで作り続けるのは難しいかもしれません。DLLの仕様変更なので、DLLの使用サンプルも、入れ替えないといけないので、それも、並行して進めています。フリーソフトの開発は、作者の技量に、余裕があるところで行われないと、意味がないと思います。仕事ではないので、納期もない(作者の都合でいつ完成させるか?なんて自由だ)。バグがあっても、修正する義務を負わない。とにかく、作者の自由意思で開発が続けられていればいいと思っています。それでも、作者のそういう都合ばかりを前面に出したところで、あまり、わがままな主張ばかりをしたくもないし、こういう立場にいる以上、作者なりの役割を果たしたいと思います。今現在の予定では、DLL新仕様版のファイルを、明日公開予定。いろんな事を書きましたが、フリーソフトを作ることを、楽しめる日々が続けばいいなぁって事ですかね。
2007年01月06日
コメント(0)
構造体の宣言や、汎用的に作った関数を集めたヘッダファイルは、あっちこっちから呼び出される事が多いので、重複して呼ばれないように、工夫しないといけないのです。#ifndef #define #endifといった、プリプロセッサ(でいいのかな?)機能を使うと、二重に呼ばれても重複しないように、2回目からは、スキップするようにできる仕組みがあります。昨日あれだけ悩まされたエラーですが、心当たりがあり、すべてのヘッダファイルの#を見直しました。どうも、私が組んだ #ifndef #endifの使い方が悪く、ちゃんとスキップしてくれていなかったみたいです。ネットで、インクルードガードで検索したら、そういう情報が、わんさかヒットしました。というわけで、#ifndef #endifを、修正したら、今までかなりの確率で出てきたエラーが、今日は、1度出たきりで、連発していたのが嘘のようです。ただ、1回出てしまったのは、これまた、理由が良く分からず、#includen順番を入れ替えたら、消えました。そんなこんなで、C版vei.dllは、mpg,wav,mp3,ac3,dtsと一気に対応ファイルを増やすことができました。とにかく、Delphiで作っていた時のように混沌としたソースになるのだけは、嫌なので、なるべく、全体を見通せるように組んでいます。週末になったら、サンプルを一度、このブログ上で、公開することにします。MPEG関係は、まだ、DELAYとか計算していないし、MPEG AUDIOも、詳細に手を出していないので、その辺を先に済ませて、次は、AVIファイルに手を出してみる予定です。このAVI、今回は、チャンク構造をなるべくまじめに解析させるつもりでいます。そうしないと、Cで組み直す意味がなくなるので。
2007年01月04日
コメント(0)
仕様変更については、ほぼ問題はなさそうです。似たような作業の繰り返し...「C版vei.dllの実現のため、とりあえず、MPEG解析のコードをDLLに実装する」昨日から取りかかっているんですが、これが、非常に難航して(いました)。[リンカ致命的エラー]Fatal: フィックスアップインデックス VIRDEFは正しくありません何だか、ちょっと、ソースを修正したり、#includeの順番を変えるだけで、さっきまで何ともなかったのに、コンパイルする度に、出てしまうのです。根本的な原因が何も分からないので、出たら最後、#includeの順番をちょっと変えたりして、姿を消してくれるのを待つだけです。「して(いました)」と、過去形になっているのは、とりあえず、MPEG解析処理を実装したvei.dllができあがったのです。(^_^)/~~一つの形式ができあがってしまえば、後は、bccの方で、新規形式のコードを書いて、bccでとりあえずのテストを行い、OKだったら、TC++の方で、vei.dllのソースに、#include "xxxxx.c"を追加していけば、問題ないという形です。更に、C版のvei.dllをこれまでのDelphi製のvei.dllと入れ替えて、videoei.exeとmini版で、同じように解析してくれるかのチェックもしています。ここでも、ちょっと、問題が、mini版では、TMemoにReFormした詳細結果を単純に流し込んでいるんですが、今までDelphiでは、#13#10というコードが、0xD 0x0Aに変換されていたので、うまい具合に、TMemoに一行ずつ流れ込んでいたんですが、Cでは、改行を\nにしていたため、0x0Aとしか変換されないためか、改行せずに、同一行になってしまいました。つまり、改行コードを、しっかり、0x0D 0x0Aとなるようにしないといけなさそうです。\r\nにすればいいんですが、その辺のことも含めて、もう、頭の中が混沌としています。vei.dllの仕様変更を公開するのは、週末あたりにしたいと思っています。現状を、整理整頓しないと、この先、お手上げになってしまいそうで。
2007年01月03日
コメント(0)
引き続き、構造体の項目の内容を検討しています。結局のところ、コンテナ名、エラー項目、コメントの欄を追加することにしました。ずっと、C版vei.dllの事を話してきましたが、実際に解析ができるところを確認している訳ではないので、MPEG解析のコードを、DLLの中に流し込んで、ホントにDLLで動作してくれるのか、そういうことをクリアしないといけないです。そういう所にも手を出しているんですが、なかなか、思うように進んでくれないです。疑問はすべて、googleで解決する以外に手がないので、なおさら。とにかく、まぁ、MPEGだけでも、DLL上で機能してくれる状態を作りたいところ。
2007年01月02日
コメント(0)
vei.dllの仕様の変更を、決行しています。具体的には、コンテナ名と、エラーの項目を追加し、真空の詳細との差異をより詰めるという作業です。ただ、困った事に、VideoCDのコンテナ名のテストをしているときに、バグを見つけてしまいました。まれに、音声が一つなのに、2つあると表示されてしまいます。ちょっと、応急処置しようとしましたが、何だか、どれもこれも不発で、これ以上手がなければ、バグを残したままにすることもあります。何だか、MPEGの音声処理を、根本的に変えたくなった。音声カウントのアルゴリズムを変えるってのもあるし。久しぶりにDelphiいじってみたけど、文法とか忘れて困るレベルでもなさそう。一旦、頭の中が切り替われば、まだ大丈夫。23:28 追記音声の数が正しくカウントできないバグは、何とか、回避する方向に進んでいます。非常に、まどろっこしい方法ではありますが、何とか不完全なカウントを避けることができています。引き続き、CでMPEG処理の方も進めたいです。MPEG AudioのDELAYの計算とか、TFFとか、ユーザーデータの読み取りとか、veiの付加情報も、取り出せないと100%じゃないので。それと、ファイル形式の振り分け~各形式の解析の流れを、そろそろ手を付けたい。
2007年01月01日
コメント(0)
全30件 (30件中 1-30件目)
1

![]()