エピ３８ まとめ --- ＣＤは読めたのか？
＊＊＊
まとめ --- ＣＤは読めたのか？
＊＊＊
ジッターの偏りにより角度０で発生するエラーを低減するため、光ピックアップ信号のパワーを参照して、しきい値を見直しました。他にもあれこれ調整しました。
エラーは０にはならないけれど、ＣＩＲＣもあるし。そろそろね。
ＣＤの１曲目の先頭部分だけど、読めたと言えるのかを確認します。
＊
光ピックアップの信号のパワーをパラメータに採用して、しきい値を見直した結果です。変更前と変更後を比べます。
エピ３５で紹介した本物のエラーは、しきい値などではどうしようもないのですが、それ以外のエラーは大部分が消えました。特に角度０に集中して発生していたエラーは滅亡。やったね！
エラーレート 0.8 以上となる時間は、フレームの番号で示すと（０分０秒を０番のフレームとして）、
2102, 2103,
3186, 3187,
3603, 3604,
4185,
4437, 4438,
6400, 6401,
7261,
7450,
11569, 11570,
12404,
です。２つのフレームが連続しているのは、訂正符号Ｃ１でエラーを検査しているからです。
どれも 108 フレーム以上離れているので怖くありません。Ｃ２で誤り訂正可能です。
フレームの番号を経過時間にしたいときは、2102 番なら 2102*588/4321800 = 0.285986 秒となります。フレームの番号は後で使います。
＊
えーと、11569 番と 11570 番のフレームについて、ちょっと確認しましょう。
エラーはＣＩＲＣによると、11569 番のフレームで発生していて、
- 11569 -
FE 89 00 BC 01 E7 00 02 -1 -1 AC 9C
51 D3 E5 4B
77 B1 77 46 77 F5 2C 6D 7E AD AF 77
0A 2B 15 36
を、
- 11569 -
FE 89 00 BC 01 E7 00 02 02 59 FE 46
93 2F 4D D7
00 73 00 A5 00 50 FE 19 01 FC FD 22
B3 F7 10 F0
と訂正したそうです。訂正前で -1 とあるのはＥＦＭ復調でエラーになったデータです。消失ですね。
チャネルビットを見ると、
100 10010000000000 010 ...
１２Ｔあったりします。これならエラーになって仕方ないです。
光ピックアップの信号を見ると、
図の横軸の時間で 0.0 μs から（600mV に注目して見てね）
６Ｔのランド（1.416μs）、
３Ｔのピット（0.696μs）、
３Ｔのランド（0.680μs）、
と続いて、その後に（恐らくですがランドが１つ消えて）ピットの長さがオーバーして、
１２Ｔのピット（2.784μs）
となったように見えます。その後の短いランドは３Ｔ未満で、以降のチャネルビットがズレて行きます。
正しいチャネルビットはＣＩＲＣによると、
正： 100 10010000100000 010 ...
誤： 100 10010000000000 010 ...
ですから、やはり 4.0〜5.8 μs は反射光が落ちてランドが消えたのですね。
経過時間が同じ、...と言うか、11569 番のフレームを含むデータは 11 個あって、エラーレート 1.0 です。これも本物のエラーと認定しましょう。
＊
同期信号の誤判定について調べてみると、データが壊れているかのように他のデータとは異質な測定データがあって、これらは外すことにしました。
ヤバイのは F701, F720, F743 の３つ。
それから、１フレームが 588T とならず、589T あるいは 586T, 587T などになるエラーが度々発生しているのですが、今回は放置しました。589T ならピットあるいはランドのどれかを１Ｔ長く判定したのでしょう。でも目をつむって、先頭から同期信号・サブコード・音楽データ・・・・と解釈していきます。
...。エラーの状況はこんな感じです。
＊
＊
＊
さて。測定データから音楽データと訂正符号を集めて統合しましょう。
バラバラのデータだと、クロスインターリーブの都合で先頭の 108 個のフレームは音楽データが部分的にしか集まらないのです。訂正符号Ｃ２での誤り訂正もできません。
つまり、データの先頭の 108/75/98 = 14.693 ミリ秒が使えないのです。
データはあるのに分断されているから使えないのはもったいないのです。
＊
目標を音楽の最初の２秒間として、98*75*2.0 = 14700 個のフレームを集めます。
サブコードを参照すればセクタの経過時間が分かり、セクタ内でのフレームの番号を加算すれば、何番目のフレームか分かりますね。
同じ経過時間のデータは最大で 15 個あるのですが、先着のデータを採用します。運が悪いとエラーを含むフレームが入るかもですが。エラーレート 1.0 のフレームがあるので諦めます。
a_sram = [0]*(98*75*2)
for f in a_f:
mm,ss,ff,f0,sram = data[f]
fs = mm*60*75*98 + ss*75*98 + ff*98 - f0
for i in range(len(sram)):
k = fs + i
if k >= 0 and k < 98*75*2 and a_sram[k] == 0:
a_sram[k] = sram[i]
サブコードから得たセクタの経過時間が mm : ss / ff です。ＢＣＤは変換してあります。セクタの先頭フレームの（測定データでの）番号が f0 です。これを使って、測定データの先頭フレームの番号を求めて変数 fs にします。変数 k が各フレームの番号になります。
変数 sram は音楽データと訂正符号の計 32 バイトを１要素とする 32 x N の配列で、N = len(sram) は測定データに含まれるフレーム数です。
変数 a_sram が統合先で、初期値 0 だったらデータを格納します。先着１名様です。
こんな感じの処理で、データは統合されました。
＊
ここから音楽データを取り出します。クロスインターリーブで 108 個のフレームに渡って分散されているので、これを集めて、それから音楽データの順番も元に戻します。
de = [ 108,105,100,97,92,89,84,81,76,73,68,65,
60,57,52,49,46,43,38,35,30,27,22,19,14,11,6,3 ]
sh = [ 0,1,8,9, 20,21,2,3, 10,11,22,23, 12,13,14,15,
4,5,16,17, 24,25,6,7, 18,19,26,27,28,29,30,31 ]
mus = []
r = [0]*32
for f in range(108,len(a_sram)):
for i in range(32):
r[sh[i]] = a_sram[f-de[i]][i]
for i in range(0,12,2)+range(16,28,2):
mus += [r[i]*256+r[i+1]-(2**16 if r[i]>128 else 0)]
m0 = mus[0::2] # left
m1 = mus[1::2] # right
変数 de と変数 sh がクロスインターリーブを解くためのオフセットです。エピ２３で出て来ました。変数 r に 32 バイトを集めます。
変数 r から変数 mus に音楽データを蓄積します。２バイトで１つの値になり、符号付きなのでその処置をします。
最後に左右のチャンネルに分けて終了です。
＊
ＣＤドライブで読み出したＷＡＶファイルがあるので、これと比較します。
左チャネルで 40 個、右チャネルで 51 個のエラーが出ました。
１つのデータは 16 ビットなので２バイト分ですが、調べたところ、２バイト同時にエラーになったところはなくて、エラー数がそのままエラーバイト数でした。
エラーは 40 + 51 = 91 バイト。
１つのフレームには 24 バイトの音楽データが入っていて、14700 個なので、エラーレートは、
91/(14700*24) = 0.000257... = 2.57 * 10^(-4)
だいたい標準的なエラーレートですかね。...、少し多いかも。もっとちゃんとやれば１桁くらい少ないはず。
＊
余談になりますが。
統合したＳＲＡＭの最初のフレーム（０番のフレーム）は、経過時間が 00:00/00 のフレームなのです。正確には経過時間が 00:00/00 のセクタの最初のフレームですが。
それで、ですね。0〜107 番のフレームから集めた 24 バイトの音楽データは、４バイトで１サンプルになるので、音楽の最初の６サンプル分になるはずです。1〜108 番から集めたデータは次の６サンプルになるはず。
ところが、このようにして集めた音楽データはＷＡＶファイルの先頭からと比較すると一致しないのです。無音状態はスルーですが、１秒を過ぎて音楽が始まったところで不一致になる。
波形を見ると僅かにズレているようなので、波形をスライドさせながら比較すると、+661 からと一致しました。661 は素数です。
クロスインターリーブのために 108 個のフレームが必要で、１フレームに６サンプル入っているので、108*6 = 648 だけ遅延するのは分かるのです。
でも、661-648 = 13 なのは分からない。13 も素数だし。
ああ、そう言えば。ジッターでＳＲＡＭ上のフレームが増減した際にエラーとならないように余裕が必要なので、２フレーム遅延させているなら、(108+2)*6 = 660 か。
とすると、661-660 = 1 だけど。１は素数ではないな。
残った１サンプルは何かな？ ...、処理中に０と１を取り間違えているかもだけど。要確認。
＊
バグを見つけた方は感想欄で教えて下さいな。是非とも！
＊
ＣＩＲＣで訂正しましょう。もう既にＣ１もＣ２も誤り訂正は経験済で処理するだけです。
Ｃ１エラーは 18 個のフレームで発生して、そのうち訂正符号Ｃ１では５個を訂正できて、残りは訂正不能でした。
2102, 2103, # ERR>0.8
3186, 3187, # ERR>0.8
3603, 3604, # ERR>0.8
4185, # ERR>0.8 <--- 1-err-cor
4437, 4438, # ERR>0.8
6400, 6401, # ERR>0.8
7261, # ERR>0.8 <--- 1-err-cor
7450, # ERR>0.8 <--- 1-err-cor
9763, 9764, # <--- 2-err-cor
11569, 11570, # ERR>0.8
12404, # ERR>0.8 <--- 1-err-cor
先に確認したエラーレート 0.8 以上のフレームが並んでいますね。例外は、9763 番と 9764 番の１組だけ。
２つのエラーが出た 9764 番や訂正不能なフレーム（の奇数バイトや偶数バイト）はＣ１ポインタ＝１です。
訂正符号Ｃ２では、検出したエラーは全部を訂正できました。どれも１バイト誤りでしたので迷わず訂正です。さすがＣ２。
Ｃ２で訂正したフレームは、
2102, 3186, 3603, 4437, 6400, 9763, 11569,
の７個でした。Ｃ２エラーは７個と数えてよいのかな？ とするとＣ１エラーは実際にエラーが出ているフレーム数で 12 個と数えるのかも？
何気に再度、Ｃ１でチェックしてみたら 14 個のフレームでエラー。よく見たら訂正符号Ｃ１を訂正している。Ｃ２で 28 バイトが正しくなって、Ｃ１自体が訂正できるようになったということだった。
全部訂正できたのでＣＵエラーは０です。
＊
このＣＤの１曲目の最初の２秒間のエラーをご報告します。
Ｃ１エラー： 12
Ｃ２エラー： 7
ＣＵエラー： 0
ＣＤの品質をチェックされている方、見てみてー
＊
訂正後の音楽データを、ＷＡＶファイルと比較します。すると、
２秒間ですが完全一致です。
ＣＤを読めたと言ってよいでしょう！
＊
ここで終了してよいかな。イイねとか思わない？
＊＊＊
間違いの指摘とか疑問とか、ご意見・ご感想とかありましたら、どうぞ感想欄に！
＊＊＊
2025.7.1 微推敲。
2025.7.5 微推敲。
2025.9.15 微推敲。
