C言語相談室(上級者専用）
■ このスレッドは過去ログ倉庫に格納されています
音声は一時停止・分割・結合できることが望ましい。難しいですか？ 昔、パソコン通信とか言って、音響カプラとかモデムとかあったよな。それと少し違うのは音声データが非可逆的に圧縮される可能性があるということ。
例えばMP3に圧縮すると、元音声波形とは少し違った形になると予想できる。また、録音時にテレビの音や人間の雑談もあり得るから、環境ノイズの特性がわからないと。うーん。 はっきりと聴覚できる音声・波形であることが第一条件。MP3圧縮しても消えない音声が第二条件。
環境ノイズに邪魔されないのが第三条件。とすると、やかましい、うるさい音になるだろう。 >>280
環境音の測定をやってみる。ありがとう。 スマホ時代に圧縮なし音声はコストが高いんだよな。どうしよう。 データを直接ピーガガカにしたいってことですか？
音楽に透かし的に埋め込むのではなくて。 >>286
そうです。環境ノイズやMP3圧縮に強い音声波形でないといけないようです。 符号拡散的にエンコードした音はどうでしょうか。
透かしと言ったけど、埋め込むのではなくそのまま使う。 >>288
その場合、おそらくフーリエ逆変換でその波形は得られる。となると、いくつか周波数の選定が必要か。 >>290
逆だよ。閉鎖環境で音で脱獄しないといけない状況で使うんだよ。 監視すり抜けるだけならデータファイル名に.mp3付けるだけでよくね？ >>294
世の中にはUSB接続が禁止された環境もある。 信号損失の問題は、losslessのflacを積極的に使うことで解決。
波形はsquareがはっきり聴こえることがわかった。 信号波形の設計。クロックタイミングの合わせ方。環境ノイズの特性の測定。信号周波数の選定。信号停止、信号終了の方式の決定。 あとオリジナルの曲(固定)をベースにしても良いなら
マスター曲をまず自分で保管しておいて
流れてくるデータ付き(劣化)曲を受け取ったら
マスターとの差分なり誤り訂正なりで
データ部分だけ取り出すアルゴリズム作れそうだし
それならクロックタイミングとか気にする必要無さそう たくさん詰め込みたい、っていう要求さえなければ、
「読み上げ」ソフトと「音声認識」ソフトの組み合わせ、と言いたいな。
プリントアウトした紙をOCRで読み取らせる、ってのと同じ趣向のネタ。 別に音楽じゃなくても数字読んでる声送れば良いのか
オデッセイみたいなローテクだな
あとはその読みをどれだけ高速化出来るかだな 1をイチと読む必要も無いしな
256通りの音を定義しておけば良い
65536通り定義出来るならもっと圧縮可能かも知れない ピーヒョロヒョロピーガーじゃだめなんやろ
ちゃんと音楽でカモフラせんといかんのやろ いろいろ考えたら、音声よりも動画の方が情報量が圧倒的に多いことに気付いた。 画面にダンプをスクロール表示させて、デジカメで動画撮影。
持ち出した先でOCRにかけるってことだな。
いや、一画面ずつ表示させちゃ、ライターに仕込んだ小型カメラで
フィルムに撮影してもいいんだけど。
……なお、このテープは自動的に消滅する。健闘を祈る。 そう言えば昔のマイコン雑誌には1画面づつ表示させて写真撮影した BASIC のリストやマシン語の16進ダンプが載っていたなあ。 雑誌として売ってるんだから当然印刷、という混ぜっ返しは置いといて、
いったんプリントアウトした紙を原稿にして印刷屋さんに回してたよね。
物理的に切り貼りした痕跡(プログラムリスト部が傾いてる)なんかも見て取れた。
データの多いゲームでリストの字数・行数を減らすための工夫だったか、
謎解き部分の難読化が目的か、Base64風というかドラクエの復活の呪文みたいに
データに使う文字種を増やしたプログラムが掲載されたことがあったけど、
PC-6001用のリストを、普通のパソコン向けのプリンタで出したせいで
DATA文で使われた「ひらがな」が正しく印刷されなくて打ち込み不可能、
次号に長い訂正リストが載った、ってことを思い出した。
その時の訂正リストの方は画面を写真撮影したものだったような。
モニタ(っていうか家庭用テレビ)の湾曲が見えた記憶がある。 ベーマガで同じ機種でも月によって文字フォントが微妙に違うってことがあった気がする。 ファミリーベーシックの後期はBGキャラクタをソースに埋めてたりしたが、どうやって印刷してあったんだっけ。 8-bit時代は、入力されたテキストを一行ずつ印字するラインプリンターが主流で、印字モードを切り替えれば、外字やグラフィック文字などが使えたはず。 ファミリーベーシックは確かに写真だったかも。
あれはプリンタなかったんだっけ。 古い70年代後半や80年代前半のマイコン雑誌だと TK-80BS とか、プリンタに接続して文字を出力する事が
困難な機種に関してはプログラムリストを画面表示して写真撮影した状態で雑誌に載っていたと思う。 >>321
それやるツールも雑誌の中の人が手製で作ってそうだよね。
いろいろなことが解析すればなんとかなる範囲に収まってて楽しい時代だった。 子供の頃はASCII形式セーブの有り難みがわからんかったわ。 compo-80だな
父がプログラム入力してくれた 調べたら TK-80BS っていう別売りのテレビ出力ボードがあったみたいね。
I/O誌あたりには、色んなワンボードマイコンに、汎用で安価なVRAMボードを
接続して使うハードウェア記事が載ってた。
あとI/O誌は、カセットテープのセーブデータの
フォーマット解析記事がやたら多かった気がする。
もしかすると一部の投稿者が、新機種の出る度に
手持ちの機材と技術で解析してたのかもしれないけど。 TK-80BS（Basic Stationだっけ）はTK-80にアドオンする拡張キット
東芝の奴が初めからTV出力持ってたな TK-80BS は、単なるテレビ出力ボードじゃなくて、
キーボードやら拡張RAMやらついてたのだな。
まさにBASICを使えるようにするための拡張キットか。
…なんだかコア構想っぽいね。 TK-80の互換機があるのな。
aitendo、TK-80を再現したマイコンボード「ZK-80組立てキット」を発売
https://hardware.srad.jp/story/19/02/07/0621259/ マイコンボードはやっぱI/O引っ張り出して何かのON/OFFをさせたりしないとつまんないよな。 >>335
ON/OFFだけならアセンブリのが短く書けたりするよね。
計算とか入るとCのが楽だけど。 Cよりアセンブラが便利と言えばローテート演算だね。
「まず端っこのビットを保存してから、符号なしでシフト、
保存しておいたビットを見て反対の端にビットORで重ねる」て操作が
キャリーフラグ経由で自動的にできちゃう。
……Cから離れて長い気がするので、ちょいと絡めた話にしてみた。 なんで C の bit 演算の仕様に入れなかったんだろうってのがいくつかあるね ローテートはCでやるにはちょっと面倒だね。
でもCの仕様に入れなかったのは、演算子を考えるのがもっと面倒だったからだな。 昔はキャリーフラグにあたるものが無い事に不満があった。
今はそんなに重要だったっけ？って思ってる。 キャリーフラグは機械語レベルなら分岐に使えるけど、Cでの活用は難しいだろうね。 仮に、予約語で演算後のキャリーを保存する変数なんかがあったらどう使うの？ 言語仕様としてキャリーフラグを扱える高級言語ってTL/1以外にあるのかな？ >344
オーバーフロー、アンダーフロー、ビットシフト時の外れたビットの有無
アセンブラ経験者ならアセンブラと同じようにつかうんじゃね？ >>346
でもコンパイラがフラグを変えないように命令を配置しないといけないってのは相当な制約で、それやるくらいならインラインアセンブラ使うほうが現実的だろ。
実際のフラグを使わず言語仕様として固定的な変数のように実装する方法もあるだろうが、それやってまでフラグ的なものを再現する利点も無い。 アセンブラの癖の抜けない人のモヤモヤ感解消用でもいいじゃん。 >>344
割り込みとかマルチスレッドとかで黒魔術化しそう >>349
割り込みとかスレッド切替で変数保存されないシステムなんて見たことないが… 蟻人間てこのサイトの人だったのか
大昔に見覚えがある て言うか、以前(2ちゃんねる時代)は 片山博文MZ てハンドルで書いてたな。 BLAKER というツール名の由来にちょいと興味がある。 PaperBack っていうソフトあったな
http://ollydbg.de/Paperbak/
作者は OllyDbg 作った人 次の案件は、ReactOSのドラッグ＆ドロップだ。
https://github.com/reactos/reactos/blob/master/dll/win32/ole32/ole2.c
このファイル「ole2.c」を編集し、メモ帳(Notepad)などのアプリへファイルアイコンを
ドラッグ＆ドロップできる機能を実現せよ。具体的には、RegisterDragDrop周辺を改造して、
WS_EX_ACCEPTFILES拡張スタイルを有するウィンドウについて、
ドロップターゲットが登録済みかのように振る舞い、WM_DROPFILESに反応するようにせよ。
ヒント。
https://github.com/katahiromz/DragDropSamples
キーワード：プロセス、SetProp
成功報酬：２万円分のアマゾンギフト券。 よく分かる解説。
GetProp/SetProp関数は、ウィンドウに任意の値を結びつける。IDropTargetはドロップターゲットを表すインターフェース。
ドロップターゲットとはドロップできる対象を意味する。
RegisterDragDrop関数は、ドロップターゲットを登録する。RevokeDragDrop関数は登録を抹消する。 RegisterDragDrop関数はSetProp関数を使って、登録したドロップターゲットの情報を保持する。
RevokeDragDrop関数はRemoveProp関数を使ってドロップターゲットの情報を破棄する。 DoDragDrop関数はドラッグ&ドロップを開始し、SetCapture関数により、ドラッグ中のメッセージ受け取りを独占する。
ドラッグ中のマウスの位置から、WindowFromPoint関数により、マウスの下のウィンドウを取得する。 可能ならばマウスカーソル位置のドラッグターゲットを取得し、対話を試みる。もしドロップ可能なら、カーソルはドロップ可能を表すカーソル形状になる。 D&Dは、あるプロセスから別のプロセスへ、プロセスをまたいだ処理になるので、プロセス間通信が必要になる。
DuplicateHandleという関数が別のプロセスにハンドルを操作する権利を与える。 少し実験して見た所、ドロップターゲットを登録したウィンドウではドロップを検出できた。
ゆえに、WS_EX_ACCEPTFILESを有するウィンドウで正しくドロップターゲットを振る舞い、WM_DROPFILESを送信すれば、問題は解決する。
報酬を三万円に増額する。できるヤツは居ないか？ >>863 それでもこの言語を選ぶ理由を知るためだ。
そなたの示す言語があるのに、なぜpythonなのか疑問を抱くのは自然なことだ。
疑問を解決する回答を望んでたが、それは得られなかった。 インストール禁止な会社のパソコンはWeb経由で実行か。
CodePadなら俺も知ってるが。そこまでしてpythonを使う価値があるかは疑問。
実行速度が重要なところは、高速な言語に変更して使い分けるとかいな？。
それは煩わしいな。高速な場面でも一通り対応できる言語のほうがいい。
ハードウェアの性能が高ければ良いとかか？。高速なプログラム言語で、なおかつ高性能なハードウェアでないと。
プログラムコードを改善して、プログラムの高速化か。高速なプログラム言語で、なおかつ高速で実行するプログラムコードでないと。
C言語でも、実行の遅いプログラムコードは価値がないし。 テディベア、聞いてくれ。
https://jira.reactos.org/browse/CORE-15554
我々は、フォントレンダリングにおいて、テキストの変形と座標変換を
完璧にしないといけない。パスの必要なテストは、
C:\ReactOS\bin> gdi32_apitest TextTransform
だ。現在、いくつかテスト失敗がある。座標変換は何か間違えている。
何らかの修正が必要だ。
ターゲットは、$REACTOS/win32ss/gdi/ntgdi/freetype.c のIntExtTextOutW関数だ。
論理座標(LP)からデバイス座標(DP)へ変換して、それに
デバイス原点dc->ptlDCOrigを足したもので
IntEngMaskBlt関数を呼ばないといけない。
LOGFONT.lfWidth、LOGFONT.lfEscapement、WorldTransformなど
さまざまな変形があるため、本当に複雑なものになっている。
今月中に解決しないといけない。 lfWidthの指定があれば、幅を調整する必要がある。
lfEscapementの指定があれば、参照点を中心にテキストを回転しないといけない。
さらにグラフィックスモードがGM_ADVANCEDなら変形行列WorldTransformを適用する必要がある。 >>375
初心者や中級者にこんなの出来るわけないだろ。いい加減にしろ。 アルゴリズムの話であってCの話ではなくない？
Cの話として上級なの？ アフィン変換の重ねがけ（ただし重ねる順は要注意）ってなわけにはいかんのかね >>373
ここは初心者に荒らされるのでもう諦めてる。
ゆとり/さとりはモラルがなさ過ぎて、どうしようもない。
とはいえ、おそらく彼等は「糞なネット」しか見たことがなく、「ましな状態」を想像出来なくての事だ。
当人達は全く荒らしている自覚がないのでどうにも救いようがない。
（治安の悪い地区に住む者が、その治安の悪さを問題視出来ないのと同じ。そういう物だと思ってる）
だから、初心者をBAN出来る掲示板があればそっちでやりたい。
(そこでゆとり/さとりにも「ましな状態」を見せないことには改善しない）
redditか8ch等で既にあればそこを利用するのが楽でいいから指定してくれ。
なければ自前で用意する事になるが、それならついでに色々準備したいからあと数年かかる。
なお再度言うが、「初心者は全員BAN」してくれるところな。「初心者用」のスレがあるだけでNGだ。 が、ちょっと気になったことを言っておく。
131の時に見た限りでは、正直、あのコードで今君がやってるようなアジャイル開発は無理だ。
コード分岐が無駄に多すぎる。
(念のため言っておくが、今のコードを見たわけでない）
> 座標変換は何か間違えている。
これについて、単純には
・変換式を間違えている
・変換式は合っているが、コードが抜けている
の2通りのバグり方があるわけだが、どっちか認識出来てるか？
君はアフィン変換も怪しかったのでいまいち信用ならないが、
普通は変換式なんて仕様通り記述すればいいだけで、間違えないし、間違うものでもない。
また、変換式自体を間違っている場合は全部failするからすぐ分かる。
通ったり通らなかったりする場合は後者、つまり、あるべき場所でコードが抜けてるとか、コードの記述場所を間違えているとかだ。
これが発生するのは、コードに無駄に分岐があるからであり、言ってしまえばコードが汚いからだ。
アジャイルで今後とも少しずつ機能を追加していく気なら、いつかコードを整理しないと破綻すると思うぞ。
全仕様をそろそろ完備ならそのままやりきってしまうのも手だが。
綺麗にするのなら、まずは以下で。
・C流の分岐をケチるのは止めて、とにかく関数を小さく切り出してOAOOを厳密に守る
・すると中/上位関数は、AやってBやってCやって終わり、みたいなアホな関数だらけになる
・そうなると、上記「変換式」を書くにはここしかない、というのが唯一1ヶ所に確定する
結果、抜けたり、間違った場所に配置してしまう、ということがあり得なくなる。
逆に言えば、抜けたり、間違った場所に配置出来るのはコードが汚いから。
OAOOが徹底された場合、ほぼ常に「この機能を追加するならここに唯一1回だけ書く」状況となり、
正しく書けば機能追加終了、間違えば全failとなり、動作は非常に分かりやすくなる。
よく分からん動作になってデバッグに手こずるのは、コード構成に問題があるんだよ。 ■ このスレッドは過去ログ倉庫に格納されています
