【C4FM】デジタル信号復調 2 【π/4DQPSK】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
各種測定器、SDR、ソフトウェアなどを最大限に利用してデジタル通信の復調にチャレンジする人たちが集うスレです。 コテハン推奨。 前スレ 【C4FM】デジタル信号復調【π/4DQPSK】 http://mint.2ch.net/test/read.cgi/radio/1434951910/ あまり知識無いのですが、このLFSRって15bitですよね?XORする際は例えばMSBに"0"等を付加して16bitにしてXORするとかなんですか?それとも無理くり15bitでXOR? >>487 15bitはそのまま使うんじゃなくて 擬似乱数を発生させるシフトレジスタにセットする初期値の15bitです wikiで線形帰還シフトレジスタで調べれば出てきますよ 皆さんお疲れ様です、僕も微塵ながら地道に挑んでます、前スレ549さんはじめ皆さん共に頑張りましょう! さて最近になってwindows側でもデコードを始めたんですが、 windows10でtail -fのようなコマンドを走らせる方法がわからなくって汗 >>337 のような疑似リアルタイムデコード表示をwindows10で行う方法わかる方がいましたら教えてくださいませ。 >>489 tail -f相当ならWindows PowerShellを使えば出来るらしいよ ええ、ググってみたらPowerShellで出来そうなんですが、記述がダメなのか上手くいかなくて >>489 >>491 Linuxと同じように走らせたいならMinGWとか使ったほうが良いのではないでしょうか? >>483 SACCHの出動の種別表示が87(???)というのが出ましたがこれは? >>493 >>494 分署の近くの公園で音声を聞きつつ、別途受信したデータと突合させるのは疲れます... やってることは不審者そのものですし >>494 >>495 なるほど...ご返答ありがとうございます。 自分も近くの音声が聞けるところで照らし合わせてみます。 どこからSACCHを判明させたのだろうと思ったら、まさかそこまでのご苦労があったとは! 情報収集ですが、くれぐれも無理をなさらないようにお願いします > 皆様 駄文失礼します >>337 に書いた擬似リアルタイムデコードですが、 (1) t61.grcの"File Sink"の"Unbuffered"をOnにして、 (2) 端末から、"tail -fs 0.1 output.bin | 101 | 503" 等と実行すると、 よりリアルタイム性が増しますのでお試し下さい (UnbufferdをOnと、tail -fs 0.1が肝です) >>499 Unbufferedいいですよね! 個人的にはfs0.2ぐらいが文字読める速度で照らし合わせるときとかには重宝です。 出動の種別表示が87(???)の時の自治体サイトなどで公開されている同時刻の出動情報を確認してみると3回中3回共に「災害」になってますね。屋内事故などでしょうか? ちなみにY浜ふぁいやーです。 まとめてのレスで失礼します >>497 音声デコードのヒントが無いかと思って出掛けましたが、ついでのほうで若干の成果があったのでした >>500 Unbufferedだと負荷に弱くなるはずなので、安全サイドに倒しておいたのですが、気のせいだったようです t61_multi.grcでも問題になりそうにないので、Unbuffededをデフォルトにしようかと思います >>501 地域によって使われている情報が異なる可能性がありそうなので、どうしようか思案中です 04/84(その他)は(警戒)かも知れんなあとも思ってますが、なにぶん情報不足なもので... 皆様お疲れ様です。 大変お手数をかけて申し訳ないのですが、もしよろしければ>>410 のファイルを再びアップしていただけないでしょうか… >>503 再upしました ご確認下さい ttp://fast-uploader.com/file/7062251279850/ 前と何も変わってませんので、既にお持ちの方はダウンロード不要です (その後にupしたものは統合されていません これはそのうち...) >>504 遅い時間に申し訳ありません。 まだまだ勉強中ですが、使わせていただきます、ありがとうございます! >>504 統合版をupしました(約51MB) ttp://fast-uploader.com/file/7063084997109/ 502,503を統合しただけで、使い方は>>223 と変わっていません よろしければお使い下さい >>507 どもです もうネタ切れなので、新たなネタが仕込めるまで篭ります... 前スレ549さん FM-807F02の実機を入手したんですが(技適末尾14) 再度ROM諸々うp出来ますでしょうか? よろしくお願いしますm(__)m >>509 再upしました ご確認下さい ttp://fast-uploader.com/file/7063533488731/ ダウンロードパスは以前と同じです 展開パスはFM-807F02に合わせてあります これでよろしいでしょうか? >>510 ダウンロードできました! 可能であれば >>130 >>140 >>240 も再うpお願いできますか? 色々と研究してみようと思います。。。 >>511 >>140 のものを掘り出しましたのでupしました ttp://fast-uploader.com/file/7063542546906/ 他のものも掘り出し次第upしますのでしばらくお待ちを... >>512 >>510 でupしたアーカイブには>>133 相当を含んでいますのでご承知おき下さい >>511 >>240 +αをupしました ダウンロードパス、展開パスは先ほどの>>510 と同じです ttp://fast-uploader.com/file/7063543512151/ +αは>>247 に書いたデバッグログの追加です ただ、インターリーブの部分はFchとは互換性が無いのが明らかになっているので、あまり参考にならないと思います >>516 元のファイルそのままなので、展開パスがEF-6190のやつになっていると思います >>517 富◯通のシステムを使っている局なら、分かることもありますという程度です >>481 インターリーブなんですが、きっかけになりそうな情報が実験で得られました 音声TCHの256ビットを、MSBから並べて0〜255としますと、 (1) 19と51に相関がみられます(19が0なら51が0、19が1なら51が1) (2) 95と127に逆の相関がみられます(95が0なら127が1、95が1なら127が0) (1)は、R=1/2の畳み込み演算の先頭に出てくるパターンと同一です(ただし秘話演算無しとした場合) 現在、19と51が隣り合わせ、かつ95と127が隣り合わせのビットとなるインターリーブパターンを探索中です... ご参考まで 共通仕様書を行政文書開示請求したら さらっと全文開示したりするかもよ? 一件300円で出きるから消防庁宛に試してみるか f f 490 c b79 d 724 0 98e c 332 9 b2e 6 035 d a3e 6 0dd f 16b 4 c3e e e49 0 e00 2 f2d 3 247 7 06 f c 490 e b79 f 724 0 98e d 332 b b2e 5 035 f a3e 7 0dd e 16b 4 c3e f e49 1 e00 3 f2d 2 247 5 06 d e f0e f 01f 0 120 1 231 2 342 3 453 4 564 5 675 6 786 7 897 8 9a8 9 ab9 a bca b cdb c dec d ef 0123 1234 2345 3456 4567 5678 6789 789a 89ab 9abc abcd bcde cdef def0 ef01 f012 0 1 2 3 4 5 6 7 8 9 a b c d e f インターリーブのパターンと関係あるのかな? 新参者です。周波数パスのヒントをお願い出来ませんか >>521 の続きをご報告します エラーフリーと思われる音声TCHフレームを統計処理して、インターリーブパターンを絞り込みました たぶんこれでOKだと思います const int voice_tch_interleave[256] = { 95, 127, 79, 111, 223, 255, 207, 239, 31, 63, 15, 47, 159, 191, 143, 175, 94, 126, 78, 110, 222, 254, 206, 238, 30, 62, 14, 46, 158, 190, 142, 174, 93, 125, 77, 109, 221, 253, 205, 237, 29, 61, 13, 45, 157, 189, 141, 173, 92, 124, 76, 108, 220, 252, 204, 236, 28, 60, 12, 44, 156, 188, 140, 172, 91, 123, 75, 107, 219, 251, 203, 235, 27, 59, 11, 43, 155, 187, 139, 171, 90, 122, 74, 106, 218, 250, 202, 234, 26, 58, 10, 42, 154, 186, 138, 170, 89, 121, 73, 105, 217, 249, 201, 233, 25, 57, 9, 41, 153, 185, 137, 169, 88, 120, 72, 104, 216, 248, 200, 232, 24, 56, 8, 40, 152, 184, 136, 168, 87, 119, 71, 103, 215, 247, 199, 231, 23, 55, 7, 39, 151, 183, 135, 167, 86, 118, 70, 102, 214, 246, 198, 230, 22, 54, 6, 38, 150, 182, 134, 166, 85, 117, 69, 101, 213, 245, 197, 229, 21, 53, 5, 37, 149, 181, 133, 165, 84, 116, 68, 100, 212, 244, 196, 228, 20, 52, 4, 36, 148, 180, 132, 164, 83, 115, 67, 99, 211, 243, 195, 227, 19, 51, 3, 35, 147, 179, 131, 163, 82, 114, 66, 98, 210, 242, 194, 226, 18, 50, 2, 34, 146, 178, 130, 162, 81, 113, 65, 97, 209, 241, 193, 225, 17, 49, 1, 33, 145, 177, 129, 161, 80, 112, 64, 96, 208, 240, 192, 224, 16, 48, 0, 32, 144, 176, 128, 160 }; これで終わりではなく、まだこれに加えて秘話パターンを求める必要があります 秘話パターン256ビットでxorした上で逆インターリーブ、先頭202ビットの逆畳み込み、その他諸々をすると84ビット出てくるので、 それと後ろの54ビットをくっ付けると138ビットのM-CELPフレームになるという算段です 秘話パターンがLFSRとかで求まれば、後ろ54ビットのxorビットが求まりますので、これでM-CELPの正常フレームが得られます (ちなみに畳み込み部202ビットの秘話パターンはトライ&エラーで求めることが可能と思われます) とりあえず以上です おおすげえぇ!超ワクワクしてきた! よく特定できましたね、インターリーブパターンどうやって解いたんですか? >>528 19:51と95:127が畳み込み関連というのが分かったので、まず深さ32ビットのインターリーブをかけて、隣り合うビットを特定しました その上で、19:51と95:127のどちらかが先頭だろうと目星をつけたところ、95:127のほうが正しいっぽい、となりました 具体的には、95:127が01と10になっているので、それを別々のフレーム群に分割して、00/01/10/11のうち、 いずれか2つのみで構成されているビットペアの位置を検索し、それを分割し、またまた検索し... とやって、ある程度パターンが見えたところで見切った形です エラーの無いことが保証できる数千フレームを処理すれば完全な形が見えると思います インターリーブパターン、縦列で見れば 6,8,5,7,14,16,13,15,2,4,1,3,10,12,9,11列の配列なんですな。 ブロックに分けると | 6,8,5,7 | 14,16,13,15 | 2,4,1,3 | 10,12,9,11 | 更に配列順を見ると | 2,4,1,3 | 2,4,1,3 | 2,4,1,3 | 2,4,1,3 | そんでもってブロックを配列順で見ると | 2 | 4 | 1 | 3 | ほおお、なるほどなァ 言いたい事伝わったかな?(笑) ここまで丁寧に解説してくれるとチンプンカンプンだった自分もおおーとなったよ ARIB STD読むと勉強になるね 前スレ549さん辺りはとり掛かってると思うけど F-chとMCAのCELPが同一規格を前提として MCAの無音データ138ビットの作成からやってみるか 大変ご無沙汰しております >>532 気付いてはいましたが、まだやっておりません > 無音データ 最近分かったことを箇条書きにしてみます ・エンコードはK=9, R=1/2の畳み込みで確定 生成多項式も0x11d, 0x1afで、CDMAと同じ ・秘話は単純なXORではない ・逆インターリーブした音声TCHデータを2ビット毎に区切り、四進数として{0,1,2,3}とすると、 パターン0:{0,1,2,3}→{3,1,2,0} パターン1:{0,1,2,3}→{0,2,1,3} パターン2:{0,1,2,3}→{1,3,0,2} パターン3:{0,1,2,3}→{2,0,3,1} の4パターンを使って変換すると逆畳み込みが可能なビット列になる 逆に分かってないことは、 ・パターン0,1,2,3のどれが二進数の00,01,10,11に該当するかはまだ不明 ・変換パターンがLFSRなのかどうかも不明 となります パターン変換マップの101文字は、以下のどちらかではないかと考えています (1) 30112210000123231133210211113212222103210220233111221033012201330002133201232302303120000211200131301 (2) 30112210000123231133210211113212222103210220233111221033012201330133102113031202303120000211200131301 無音データが入手できれば、このどちらかが正しいか、それとも両方が間違いかが分かるはずです なお、これらはあくまでも勝手な複数の仮定に基づく妄想の産物ですので、野暮な突っ込みはご遠慮下さい... >>533 この実験に使ったソースを上げておきます よろしければ参考にしてください ttp://fast-uploader.com/file/7065792921533/ 使い方: (1) まず最初にmakeを実行してvoice_tchコマンドを作っておきます (2) 503コマンドの出力(テキストファイル)を、step1.txtとリネームして同じディレクトリにおきます (3) sh step1.shを実行します(step2.txtが出来ます) (4) sh step2.shを実行します(step3.txtが出来ます) (5) sh step3.shを実行します(step4.txtが出来ます) (6) sh step4.shを実行します(result.txtが出来ます) あとはresult.txtを眺めてみてください ビットエラーがある場合は、右端に見つかった最初のエラー位置(左端を1とした文字数)が出ます >>534 ご苦労様です! 参考にさせていただきます。 >>534 の訂正です step4.shの中の数列を以下のものに換えて下さい 30112210000123231133210211113212222103210220233111221033012201330133102113031202303120000211200131301 正解は相変わらず分かっていません... >>536 補足です この数列パターンは、無音部のパターン2つのうちの1つが全て0でデコード出来るようにしたものです (これが現状の大きな仮定のひとつです) この数列によって、現状、エラー検出とViterbi的なエラー訂正が可能になりました この数列を使ったデコード済みビット列は、末尾にある8個の0(畳み込みのパディング)を除き、MCAデジタルのフォーマットとよく似ています MCA: 5+18+43+23+4+8 = 101ビット Fch: 4+23+43+18+5+8 = 101ビット フォーマットをMCAデジタルと同じにするには、Fchのビット列を逆順に読むだけで良さそうな雰囲気ですが、はたしてどうでしょうか? ともあれ、正しい数列が見つかれば、先に進めそうな感じです >>537 お疲れ様です。 解析が進むにつれ、やはりFのMCAとの類似点が増えてきましたね。 >>538 どもです 自分でもかなりいい所まで来てる実感があります デコード後のhash値の演算も通ったので、あとはビットの組み換えをすればM-CELPの本体へ渡せそうです (訂正) >>537 で書いたMCAとFchのビット構成ですが、正しくは MCA: 4+18+43+23+5+8 = 101ビット Fch: 5+23+43+18+4+8 = 101ビット でした なるほど・・・と、言いたかったが頭がついていかん(笑) しかしながらかなり複雑な仕様なんだと理解できた、並の努力じゃここまで判明しなかったでしょう。 前スレ549さんのお手伝いしたかったが、結局ここまで何も出来ず。 お弁当の差し入れくらいしたかったぜ、お茶付きで。 ちなみに質問ですが、これらは移動局側にも適用できる感じですか? >>540 ここまで来るのに、何だかんだで1年近くかかってますね... 成果物は、ほぼ全て公開しましたので、普通に使ってもらって過程を楽しんでもらえたら嬉しいです 完璧な結論を早く出せ!と仰る方には、ごめんなさいをしておきます 移動局(uplink)のほうは、通常時は大丈夫そうです 手元でも幾つかデコード出来ています >>442 のようなパターンが出るとダメですが... (逆畳み込みは出来るのですがその先が不明) ご回答ありがとうございます、やはり反映できるのですね! 私も>>442 のパターンが解けるかどうかが関心事でした。 デフォルト外の秘話設定ぽかったりします? 今後音声をデコードできるようになれば、未確証だった団体コードや出場種別等々、判明することも多いかと思うので今後が楽しみです。 >>542 正確に記述しますと、>>442 のパターンは全てが ・逆畳み込み:OK ・ハッシュによるフレームエラーチェック:OK なので、他の受信フレームと同様に並び替えをしてM-CELPへ渡せば良さそうなのですが、 ぱっと見の心象が悪いビット列なのです(ここは完全に主観です) M-CELPデコーダを動くようにして、このビット列を突っ込むまで本当のところは分からないです 現状、これは今後のお楽しみということで何卒宜しくおねがいします コーデック自体が一般流通してないもので、かつ権利・著作物の関係で不特定多数への配布に難があるから、だからとりあえずは中古であれコーデック吸い出した実機同様のEF-6190を持っておきましょうよ、という事だと思いますがそういう解釈で合ってますかな? >>548 自分的にはまさにそういう意図でお願いしています CELPアルゴリズムに著作権は及ばないのですが、コードブック部分はどうしても回避出来そうにないので... コードブック部分の自動生成が出来るようになったら事情が変わるかもしれません EF-6190っていろんな会社が製造してるんだな アイコムやパナソニックがメインみたい >>550 製造してるのは三菱1社。 その他のメーカーはOEM供給を受けて販売しているだけ。 もしM-CELP突破できればの話ですが、同じ三菱系のJRデジタルの解析にも応用できる可能性があるのでしょうか? >>534 デコードした結果を使ってM-CELPのデータ構造を組み立てるように追加コーディングしました ttp://fast-uploader.com/file/7066297450891/ 使い方は>>534 と同じです 前回から、次の点を加えてあります (1)hashの計算と比較 (2)MCAのデータ形式への変換と表示(2進数) (3)M-CELP形式への変換と表示(16進数) また、引数に与えていたマジックナンバーを内包しました これは、voice_tch.c先頭近くにある#undefを#defineに変更すると以前と同じ仕様になります まだ出力結果は評価出来ていません(DSPのシミュレータを動かせる人求む!) みなさんの実験のベースとして参考にしていただけるとありがたいです MCA実機でNECチップの型番ググっても全く情報出てこない オプション?外部端子の通信用みたいで無視しても構わなそうだけど気になる >>553 お疲れ様です。 いつもありがとうございます。 ダウンロードさせていただきます。 Code Composer Studio とチャイナ製のJTAGアダプタで 実機デバッグできて色々とイジれそうですね〜 TMS320C54x. のシミュレーター見つけたんで貼っときます gdspsim.sourceforge.net >>556 CCSのシミュレータで検証 C54x用はCCSのVer4以上では含まれておらず Ver3はダウンロード出来ず断念 gdspsim CentOS上で実行してみたけど実用的じゃない・・・ 実機で検証用にJTAGアダプタ入手待ちです だれか動作環境のあるかたチャレンジ求む!! CCS Ver5だとC55xのシミュレータが実行出来て C55xはC54xとソフトウェア互換らしいのでMCAのバイナリ読ませて 実行までは出来たんだけどC55xから実装された可変命令長が邪魔して 逆アセみるとニーモニックが変になってる・・・ C55xのアセンブラでC54x互換モードが有るらしい C54xのバイナリを逆アセンブル→C55xでアセンブル CCS Ver5のC55xシミュレータで旨く行けば実行出来る? このC5509A評価ボードに付いてくるDVDにはCCS3.3が入っているみたい。だれか試しに買わない? ttps://www.aliexpress.com/item/free-shipping-DSP-development-board-DSP5509-development-board-TMS320VC5509A-development-board/32607704473.html >553 お疲れ様です。自分の環境でも state = 0x00 : OK !! が出ました。 これを>515に入れてみたいのですが、どうやったらいいでしょう? PCMが出ればwavにしてみます。よろしくお願いします。 >>561 あのソースはまだ不完全で、鋭意デバッグ中ですので、もうしばらくお待ち下さい (現状だと何を入れても全部0の出力しか出ません) こんにちは Fchデコーダーを改版しました ttp://fast-uploader.com/file/7066959438477/ いつも通り、gcc -o 504 504.c でコンパイル出来ます 503からの変更点は、 (1) >>553 の成果を取り入れて、音声フレームのCELPフレームへのデコードと表示を行うようにしました (2) RCH/SACCHのデコードを、スーパーフレーム末尾で無く、逐次に行うようにしました (3) RCHのデコード結果を、成功した場合にのみ表示するようにしました (4) SACCHの無効フレーム時には、invalidを含め何も表示しないようにすっきりさせました (5) (S/F)ACCHの出動種別87(disaster)を追加しました (>>501 さん御提供) (6) その他、細々とした高速化を図っています です 使ってもらって感想をいただけるとありがたいです >>563 の付け足し CELPのフレームですが、9word(18byte)分の16進表記で、先頭からの138ビット+1ビットを使っています +1ビットは、hash計算エラーのフラグです(1なら失敗) 実機シミュレータならば、 (1) 0x6792に1を書き込んで逆畳み込みを抑止 (2) 0x292aaを呼び出してセッション初期化 (3) 0x6550~の9wordにCELPフレーム+フラグを書き込み (4) 0x29365を呼び出してデコード (5) 0x6650〜の320wordのPCMまたはμ-LAWデータを読み出し (6) セッションの間、(3)〜(5)を繰り返し となるはずです(未検証) また、EF-6190実機の音声録音バッファも同じデータ構造のはずですので、ここを乗っ取れれば実機から音声が出力できるはずです(未検証) これにはデバッグシリアルを探し当てることが必須です >>515 のプログラムは、何か根本的なところ(ALUを使った演算部のエミュレーション?)が間違っているのでまだ動きません 全面的な書き直しを含め、今後の作業を悩み中です >>563 表示がゴチャゴチャして非常にうざいので、スッキリさせたバージョンを作りました ttp://fast-uploader.com/file/7067419362771/ gcc -o 600 600.c でコンパイル出来ます 比べてみてご意見下さい >>565 いつもありがとうございます。使わせていただきます。 差し出がましいですが、常時記録だとFREE時省略のオプションなども欲しいかも? >>566 手元ではこんなのを使ってます ttp://fast-uploader.com/file/7067506803987/ コンパイル後、 101 < output.bin | 299 | 600 という感じに、間に挟んで使います (こういう意味じゃ無かったらすみません) >>567 おお、まさにこれです!ありがとうございます。 大変お疲れ様です。 >>565 MCA→CELP変換テーブルのあるROMアドレスをご教示いただけますか。 565ですと、24,25、127が2つあるので。 ※想像ですが、81番目が14、82番目が15、114番目が126かなと 思っています・・ >>569 あぁ、やっちまいましたね... > 自分 早急に見直します.... なお、テーブルですが、ROMのPAGE1の0xfaf4〜0xfb7eと0xfb7f〜0xfc09になります 前者がワードオフセットで、後者がビットマスクです >>570 >>569 さんのご想像通り、その3ヶ所が間違えていました >>553 の voice_tch.c, >>563 の504.c, >>565 の600.cに影響があります 以下の配列が正しいものになります const unsigned char celp_conv_table[139] = { 41, 42, 43, 18, 19, 20, 21, 22, 84, 85, 44, 45, 46, 47, 86, 87, 88, 89, 90, 91, 23, 24, 25, 26, 27, 28, 48, 49, 50, 51, 52, 92, 93, 94, 53, 95, 96, 97, 98, 99, 100,101,102, 54, 0, 55, 1, 2, 3, 4, 5, 56, 57, 58, 59,103, 60, 61, 62,104, 105,106, 63,107,108,109,110,111,112,113, 114, 64, 6, 65, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 66, 67, 68, 69, 70, 115,116,117, 71,118,119,120,121,122,123, 124,125, 72, 29, 73, 30, 31, 32, 33, 34, 74, 75, 76, 77,126, 78, 79, 80,127,128, 129, 81,130,131,132,133,134,135,136,137, 82, 35, 83, 36, 37, 38, 39, 40,138 }; お手数ですがコピペしてご使用下さい どなたかMCAの無音CELPフレームの取得に成功された方がおられましたら、いただけないでしょうか... MCAってT85でしたっけ?ちょっと試してみようかな。 どなたかT85のgrcのブロック組み立てた方いますか? >>574 拙作t79.grcの周波数を変えて試してみてください >>575 お返事遅れてすいません、早速周波数部分を変更して使用させていただいております。 タイミングが悪いのか通話してる波がなかなかキャッチできないっす笑 >>576 毎回異なるスクランブルがかかっているはずです... 総当りすればいけるのかもしれませんが 一か月位かかって中国からDSPエミュレータ届いたんだけれど 象にでも踏みつぶされたように破損してるよ!! また送ってもらうのに早くて半月位かかるな〜 >>228 亀レスですが... UEFIブートが有効になっているとGRUBが起動すると思いますが、どうもこの周辺にバグがあるようで、 casper-rw等が正常にマウント出来ないようです BIOSでUEFIブートを切るとUNETBOOTINになりますが、こちらでは正常にマウントされて起動します (手元で再現しました) ご参考まで... やっとDSPエミュレータが届いたぞ! 色々と忙しいんで、ゆっくりとやってみますよ dat落ち防止保守。前スレ5494は元気に頑張っておられますか。 たいへんご無沙汰しております >>582 インフルエンザで寝込んだりしていましたが、何とか生きてます 近況としては、CELPのデコーダを全面書き直しして、止まらずにピロピロ音が出るようにはなったのですが、 正常に動作させるには、現状のフレームフォーマットを2ひねりくらいする必要がありそうな感じです 引き続き、>>572 の無音フレームの取得に成功された方をお待ちしています よろしくお願いします 549様おつかれ様です。 >>569 >>570 offset→CELPワード、fbit position→ワードbit位置かなと想像して f7daと格闘・年越しましたが、そもそも同じ変換テーブルにできませんでした… (2f7f4、2f803に関連する0x720cの謎が解けず、無理やり並べても 44,46,47,48,49,50,72,…,128,129,138にしかなりません) 関連しそうな関数f605とf5cbは、自分にはもう完全にお手上げのため 大変恐縮ですが、0x720cの意味合いについて 何かヒントをいただけませんでしょうか。 >>584 かなり良い所までいっている気がします まず、44,46,... ,129,138 の隣に0...138の番号を書きます 次に、44,46,....,129,138 を昇順にソートします そして、隣の番号を順に読むと... というわけです 参考までに自分が求めたときの表を上げておきます ttp://fast-uploader.com/file/7071996969638/ >>584 肝心なところを書き忘れました 0x720cは、ページ0のアドレス=RAM(ワークメモリ)を指すものだと思います 手元の解析メモでは、Viterbiデコーダーの出力(84ワード)と書いてあります (だいぶ忘れてしまっていますので正確さは保証の限りではありません すみません) ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる