メモwiki (主にコンピュータ関連)
http://w.atwiki.jp/jennychan/
メモwiki (主にコンピュータ関連)
ja
2017-03-07T08:24:11+09:00
1488842651
-
トップページ/コメントログ
https://w.atwiki.jp/jennychan/pages/21.html
- 興味深く、RD-X4のHDD解析読ませてもらいました。当方所持のX4のHDDがよく飛ぶため初期化を良くするのですが、撮りためた番組が死ぬので困ってました。DVDもWD3002は不良品らしく、今度自力でDVDを交換するのでできれば、HDDを初期化する前に、データを吸い出したいため本HPにたどり着いた次第です。貴殿が作成されている抽出用のプログラムって公開してないですよね?もし問題なければいただければ嬉しいのですが・・。ご無理を承知で一応書かせていただきました。どちらにしろ、記事を参考にさせていただきます。 setura@ne92.jp -- (yan) &size(80%){2008-02-06 17:09:36}
- DVDドライブ型番間違えてました。訂正します。SD-W3002でした(_ _) -- (yan) &size(80%){2008-02-06 17:11:35}
- yanさんこんにちは。抽出用のプログラム公開ですか…。抽出をするプログラムはあることはあるのですが、汎用的にしようとするとUIが複雑になるので、抽出する度にソースコードを書き換えていたのです。いずれ公開しようとは思っていたのですが、いつの間にか一年経ってしまいました(苦笑)。今すぐ公開は厳しいですが、何とかしたいとは考えています。ちなみに、この、抽出プログラムをC#で作成したので、「C#メモ」があったりするのですが…。 -- (じぇにぃ) &size(80%){2008-02-13 19:11:46}
- 同じく私もRDの解析を読ませていただいております。私自身まだHDDRecは持ってないのですが、知り合いの物が再生・録画ともに不可となったことから情報を集めていました。大変参考になりますが、内容にまだついていけておりません。ダンプを見ながら何日も経過しています。。。 -- (eGu) &size(80%){2008-02-15 12:54:57}
- すみません改行してしまいました。ダンプをみるとやはり奇数偶数バイトが入れ替わっていますよね。0000BA01で途中から50MB程切出した物を単純に2バイトでスワップしても再生が出来ません。動画データだけ抜きたいのですがそんな単純にはいかないんでしょうか。。。 -- (eGu) &size
2017-03-07T08:24:11+09:00
1488842651
-
RD-X4のIFOファイル
https://w.atwiki.jp/jennychan/pages/20.html
DVD-RAMのIFOファイルの情報を元に、RD-X4のIFOファイル(TS_HDDMG.IFO)を見てみると、かなり似通った構造である事が分った。
IFOファイルのブロックは、DVD-RAMのものと若干異なり、
-ヘッダ
-プレイリスト
-クリップリスト
-不明1
-タイトルリスト
-ベンダ情報?
-不明2
と、ベンダ情報と思われるデータブロックの後ろ、というか、IFO全体の長さの先に、不明なデータブロックが見受けられる。
**ヘッダ
データブロックが若干異なる事もあり、ヘッダ情報は、以下の様な構造となっている。
| 位置 |長さ| 内容 |
| 0000 | 0C | 識別子('DVD_RTR_VMG0') |
| 000C | 04 | このIFOファイルの終端位置(= ファイル長 - 1) |
| 0010 | 04 | 「プレイリスト」ブロックの終端位置(ここまでが、本来のIFOブロックなのか?) |
| 0104 | 04 | 「クリップリスト」ブロックの開始位置 |
| 0108 | 04 | 「不明1」ブロックの開始位置 |
| 0134 | 04 | 「タイトルリスト」ブロックの開始位置 |
| 0138 | 04 | 「ベンダ情報?」ブロックの開始位置 |
| 0168 | 04 | 「不明2」ブロックの開始位置(0x000cで指定された位置の後ろを指し示している) |
**クリップリスト
DVD-RAMと若干異なり、フラグ情報が0x00000102となっており、
| 位置 |長さ| 内容 |
| 0000 | 04 | フラグ?(0x00000102) |
| 0004 | 04 | このブロックの長さ相対的な終端位置(= ブロック長 - 1) |
| 0008 | 78 | 不明なデータ列 |
| 0080 | 02 | クリップ数 |
| 0082 | 04 * クリップ数 | クリップ情報への相対位置配列 |
の様な構造になっている
DVD-RAMのIFOと比較したとき、
| | DVD-RAM | RD-X4 HDD |
| フラグ | 0x00000101 | 0x00000102 |
| 0x08からの不明なデータ列長 | 0x3c(60)
2007-03-28T22:07:48+09:00
1175087268
-
DVD-RAMのIFOファイル
https://w.atwiki.jp/jennychan/pages/19.html
タイトルとクリップの紐付け情報が記録されていると思われるIFOファイルの構造を調べてみるために、DVD-RAMのIFOファイル(VR_MANGR.IFO)を見る。
この構造は、DVD-VR(DVD Video Recording Format)仕様のものだと思われる。しかし、DVD-VRの仕様書を見つける事が出来なかったので、地道に色々なデータを書き込んで検証する事に…。
とりあえず、色々な形式のIFOファイルの資料を見ていると、IFOファイルの内部は、複数のデータブロックの寄せ集めらしい事が分った。
また、これらのデータブロックに対するアドレス指定が、ヘッダの中に記述されているらしい事も。
と言う事で、以下のブロックがあると思われる(当然のことながら正式名称は不明)
-ヘッダ
-プレイリスト
-クリップリスト
-不明1
-タイトルリスト
-ベンダ情報
※これらのブロック中の数値はBig Endian
**ヘッダ
| 位置 |長さ| 内容 |
| 0000 | 0C | 識別子('DVD_RTR_VMG0') |
| 000C | 04 | このIFOファイルの終端位置(= ファイル長 - 1) |
| 0010 | 04 | 「プレイリスト」ブロックの終端位置(ここまでが、本来のIFOブロックなのか?) |
| 006C | 04 | ディスク番号? |
| 00A2 | 3D | ディスクタイトル |
| 0100 | 04 | 「クリップリスト」ブロックの開始位置 |
| 0104 | 04 | 「不明1」ブロックの開始位置 |
| 0130 | 04 | 「タイトルリスト」ブロックの開始位置 |
| 0164 | 04 | 「ベンダ情報」ブロックの開始位置 |
**プレイリスト
ヘッダ中に、このブロックの開始位置を示す数値は見当たらず、ファイルの先頭から0x200の位置から始まる。
したがって、このブロックは、ヘッダの一部と解釈するほうが正しいのかも。
| 位置 |長さ| 内容 |
| 0000 | 04 | 有効フラグ? (1: プレイリストあり、0: プレイリストなし) |
| 0004 | 04 | このブロックの長さ相対的な終端位置(= ブロック長 - 1) |
プ
2007-03-28T21:40:51+09:00
1175085651
-
タイトルとチャプタ
https://w.atwiki.jp/jennychan/pages/18.html
RDシリーズを購入する人の多くは、CMカットなどの編集機能を求めて購入していると思われます。
ここでは、
-録画した直後のタイトルデータ
-CMカットなどの編集を行った後のデータ
の違いについて整理してみます。
**録画した直後のタイトルデータ
-録画したデータは、MPEG-2 Program Stream形式のデータ
-このデータのタイムスタンプは0(秒)から始まり、途中でタイムスタンプが飛ぶことはない(30分録画した場合、ストリームデータの最後のタイムスタンプは30分になっている)
**CMカットなどの編集を行った後のデータ
まず、CMカットなどの編集とは、
-チャプタを作成 → 不要なチャプタ部分を削除
-チャプタを作成 → プレイリストを作成 → プレイリストをHDDやDVDへ高速ダビング、DVD作成
を指すものとします。
そこで、このような編集作業を行った結果、(当たり前なのですが)不要な部分がタイトルデータに含まれていない状態になります。
RD-X4では、高速ダビング実行時に、タイムスタンプを変更しないので、60秒の直後に、150秒が来るなど、タイトル中のタイムスタンプが途中で飛んだり、編集の仕方によっては、遡ったりします。
また、タイトル結合でも同じ様なことになります。
**クリップ(仮称)
大抵のデコーダシステムは、画像や音声を出力するタイミングが取りづらくなるので、ストリーム中のタイムスタンプは単純増加していてくれないと困ります。
しかし、編集を行った後のデータは、タイムスタンプが不連続で、デコーダの要求に合致しません。
ところで、RD-X4に限らず、複数のタイトルを連続再生する事が出来ているので、「タイムスタンプの不連続なんて関係なのでは?」と思うかもしれませんが、これは、タイトル終了時点で、デコーダのタイムスタンプ情報をリセットする事で可能としているのです。
これと同じように、一つのタイトル中のデータを、タイムスタンプが非連続となる点で分割した、複数のストリームの塊として、一つの塊の再生が終了した時点で、タイムスタンプ情報をリセットし、次の塊を再生するようにすれば、デコーダのタイムスタンプ問題は解決できます。
と言う事で、(この推測通りかは定かではありませんが)実際のRD-X4で
2007-03-28T03:43:02+09:00
1175020982
-
C#言語でWin32 API
https://w.atwiki.jp/jennychan/pages/17.html
大抵の場合は、Win32 APIを使用しなくても済んでしまうのですが、たまに必要なときがあります。
**ファイルIO
.NET FrameworkのSystem.IOクラスでは、「\\.\physicaldrive0」などの物理ドライブに対するアクセスが出来ないので、CreateFile APIを使用する事になります。
参考資料は、[[Windows の ReadFile 関数を使用する>http://msdn2.microsoft.com/ja-jp/library/2d9wy99d(vs.80).aspx]]で、ポイントは、
-DllImportでDLLとAPIを指定する
-プロジェクトのビルドプロパティで、「アンセーフコードの許可」をチェック
となります。
ただし、MSのサンプルでは、CreateFileメソッドの返却値が0以外のときは成功としているのですが、無効なドライブを指定した時は、0xffffffffが返され、正常終了扱いとなってしまいます。
なお、「\\.\c:」の様な、論理ドライブに対する処理は、System.IO.DriveInfoクラスを使用すれば可能です。
System.IO.DriveInfo = new System.IO.DriveInfo("c");
Console.WriteLine(string.Format("{0} {1} {2}Byte(s)",
info.ToString(), info.DriveFormat, info.TotalSize));
全てのドライブを取得するには、staticメソッドのGetDrivesを使用します。
foreach (System.IO.DriveInfo info in System.IO.DriveInfo.GetDrives())
{
Console.WriteLine(string.Format("{0} {1} {2}Byte(s)",
info.ToString(), info.DriveFormat, info.TotalSize));
}
MSの[[Windows の ReadFile 関数を使用する>http://msdn2.microsoft.com/ja-j
2008-01-04T01:38:52+09:00
1199378332
-
HDDの中を見る(UDF編)
https://w.atwiki.jp/jennychan/pages/16.html
UDFの基礎を踏まえて、RD-X4のHDDを見る。
なお、IDE HDDのセクタ長は512バイトであるが、ここでは、ファイルシステムの設定どおり、セクタ長を2048バイトとして記述していく。
256セクタ目までは、
|セクタ| 識別子|
|0~15| 未使用|
|16| Beginning Extended Area Descriptor|
|17| Volume Structure Descriptor(NSR03 Descriptor)|
|18| Terminating Extended Area Descriptor|
|19~31| 未使用|
|32| Primary Volume Descriptor |
|33| Implementation Use Volume Descriptor|
|34| Partition Descriptor|
|35| Logivcal Volume Descriptor|
|36| Unallocated Space Descriptor|
|37| Terminating Descriptor|
|38~47| 未使用|
|48| Logical Volume Integrity Descriptor|
|49| Terminating Descriptor|
|50~255| 未使用|
|256| Anchor Volume Descriptor Pointer|
の様になっている。
Partition Descriptorには、
|Partition Starting Location|0x110|
|Partition Length|0x0746944a|
の値が記録されている。
これらは、論理セクタの配置で、
-論理セクタ(0)は、物理セクタ0x110から始まる
-論理セクタは、0x0746944a(122065994)セクタある
という意味になる。
このセクタ数に関しては、Logical Volume Integrity Descriptorでも、
|Size Table|0x0746944a|
と同じ値が指定されている。
また、Anchor Volume Descriptor Pointerは、
|Main Volume D
2007-03-14T17:52:58+09:00
1173862378
-
UDF(Universal Disk Format)
https://w.atwiki.jp/jennychan/pages/15.html
一番最低のレベルではあるものの、データの抜き出しに一応成功したとはいえ、タイトル単位で抜き出せない事には意味が無い。
そのためには、UDF(Universal Disk Format)を勉強することに…
UDF(Universal Disk Format)は、ファイルシステムの一種で、DVD-RAMの標準フォーマットとしても採用されている。
[[OSTA(Optical Storage Technology Association)>http://www.osta.org/]]を中心に規格化されている。
また、UDFは、ECMA-167を参照しているらしい。
というか、本質的な部分は、ECMA-167で定義されている。
※[[ECMA(European Computer Manufacturer Association: 欧州電子計算機工業会)>http://www.ecma-international.org/]]
2007年2月末時点では、
-UDF 2.6
-ECMA-167 3rd Edition
が最新らしい。
とりあえず、
-Volume and Boot Blockから始まり、Volume Structureが続く
-Volume and Boot Blockは、Volume Structure Descriptorから始まり、StandardIdentifierの値によってDescriptorの意味を示す(ECMA-167 Part2)
-Volume Structureは、Descriptor Tagから始まり、TagIdentifierの値によってDescriptorの意味を示す(ECMA-167 Part3)
-Descriptorデータはバイト単位で記録され、ワードデータの場合、Little Endianで記録される(ECMA-167 Part1 7.1)
-DVDメディアのセクタ長は2048バイト
-セクタ番号は、0から始める
くらいは、理解していないと話しにならない模様。
※packが2048バイト固定だったのは、ここから来ている??
**Volume and Boot Block
[volume recognition sequence] {
<CD-RO
2007-03-14T16:23:30+09:00
1173857010
-
HDDの中を見る
https://w.atwiki.jp/jennychan/pages/14.html
''「高速ダビング」の処理速度を考えると、DVD-RAMのデータと同様な形式でHDDに記録されているのでは?''
という予測を立ててみた。
この予測通りなら、packデータの連続性を補完することが出来れば、最低限ではあるものの、「見られるデータ」が取得できることになる。
そこで、HDDの中身を見る前に、RD-X4で記録したDVD-RAMのデータを見ると、
-2048バイトごとに、pack_headerが現れる = packは2048バイト固定
-MPEG_program_end_codeは存在しない
-タイトルのsystem_clock_referenceは常に0から始まる
-ただし、タイトルではなくチャプタを高速ダビングしたときのsystem_clock_referenceは0から始まらない → オリジナルのsystem_clock_referenceが引き継がれている
-system_headerは、45045/90000秒ごとに現れる
-同一タイトルと思われる範囲のデータで、system_headerを含むpackからある程度の長さのデータを抜き出して、拡張子mpgのファイル化して再生を試みると再生できる
となっていた。
つまり、この予測を確認するためには
-2048バイトごとに、「00 00 01 BA」のバイト列が出現する
という事が確認できれば良いということになる。
ということで、「00 00 01 BA」のバイト列を探すプログラムを作成し、実行してみたが、無かった。
暗号化でもしているのかと思い、100GB目くらいの辺りのデータを見ると、
00 00 BA 01 ....
というデータが2048バイトごとに現れている。
要するに、&size(medium){2バイト単位でバイトスワップしている}ということらしい。
まぁ、CPUと、IDEコントローラの間のバイトオーダが異なっている事から、PCで見たときにスワップして見えるとかなのでしょう。
ということで、バイトスワップを考慮してHDDを再度チェックすると、先頭から0x000FA110 * 0x800バイト目から始まっていることがわかった。
また、たいていのファイルシステムは、複数のセクタを一まとめにしたクラスタという単位でファイルアクセスを
2007-03-04T14:22:06+09:00
1172985726
-
MPEG-2 Program Stream
https://w.atwiki.jp/jennychan/pages/13.html
概要については、[[MPEG-2解説@Pioneer>http://pioneer.jp/crdl/tech/mpeg/3.html]]が詳しい。
以下、MPEG-2の規格を見ていくと…
MPEG-2 Program Streamは、
MPEG2_program_stream() {
do {
pack()
} while (nextbits()==pack_start_code)
MPEG_program_end_code // 32 bslbf
}
と、1個以上のpackが連続したもので、最後に、MPEG_Program_end_codeが付く。
※MPEG_program_end_codeは、0x000001B9
packは、
pack() {
pack_header()
while (nextbits()==pack_start_code) {
PES_packet()
}
}
と、pack_headerから始まり、0個以上のPES_packetが連続するデータ。
※pack_start_codeは、0x000001BA
pack_headerは、
pack_header() {
pack_start_code // 32 bslbf
'01' // 2 bslbf
system_clock_reference_base[32..30] // 3 bslbf
marker_bit // 1 bslbf
system_clock_reference_base[29..15] // 15 bslbf
marker_bit // 1 bslbf
system_clock_reference_base[14..0] // 15 bslbf
m
2007-03-03T21:02:16+09:00
1172923336
-
RD-X4 HDD解析
https://w.atwiki.jp/jennychan/pages/12.html
ある日、「ディスクに問題があり、再生以外できません」というメッセージが出てしまいました。
「見るナビ」でタイトル一覧を見ようとすると、「表示する内容がありません。」と表示されるので、DVDディスクに書き出す事も出来ず。
しかし、HDD残量は少ないので、ファイルシステム的には録画データが残っている状態らしい。
メーカー的には、録画データをあきらめて、ハードディスクを初期化しなさいということらしいが、諦めが悪い性格と、仕事でMPEG-2 Systemsの経験があるので、データの吸出しにチャレンジしてみました。
ちなみに、RD-X4は、非EXです。
-[[部品交換]]
-[[MPEG-2 Program Stream]]
-[[HDDの中を見る]]
-[[UDF(Universal Disk Format)]]
-[[HDDの中を見る(UDF編)]]
-[[タイトルとチャプタ]]
-[[DVD-RAMのIFOファイル]]
-[[RD-X4のIFOファイル]]
2007-03-28T22:03:15+09:00
1175086995