|
（約14000字）
[3623]の補足です。
・[3623]
> 営団南北線でいう「接近サイン音」にあたるものも、駅の（広い意味で）出資者（※URや自治体、土地区画整理組合）の希望に沿ったものにしようとした気配が感じられますが、結局は「ATOS」で1種類になったと、こういうわけです。
> > JR東日本へのヒアリング調査から
> > ベル音楽の作曲に関しては、専門の業者が担当しており、そこからJRへ「テーマ音」として幾つかのメロディーが提供される。各音楽には曲名及びROM番号がついており、その番号をもとに各駅ごとに、どの音楽を使用するかを選択している。ベル音楽が普及し始めた当初、どのメロデイーを採用するかは各駅の駅長の意思に委ねられており、その結果、駅同士・線区同士の系統性、また同一駅内でのまとまりなどに対する配慮が全く欠けてしまうこととなった。
まったく憶測ではございますが、ATOSを含むCTC（PRC）での「音片」というのも、内容に対する番号（例えば音片IDみたいなもの）および、音声ファイルの実際の内容（例えばハッシュ値やファイルサイズ）と、放送すべき内容との不整合を起こさぬよう、例えば音声ファイルのハッシュ値みたいなのを管理なさっておられるというようなことはないでしょうか。（あくまで憶測です。）
・（参考）C言語とJavaは一通り、次はPHPです！ ご注文は「md5_file」のふいんきですか？？
http://php.net/manual/ja/function.md5-file.php
・[3623]
> キユーピー「ピーマンの基本情報」
> > 基本情報合格への道をピーマンが徹底解説
> …じゃなくて！！
（駅長でなく指令に権限があるという意味での）CTC（※同じく、そういう意味でATOSを含む）で「詳細な自動アナウンス」を流すにあっては、「接近放送」にあって、誤った種別を案内してしまうことや、あまつさえ通過列車に対して誤った停車列車の案内が流れることのないよう、また、指令側の装置（中央装置）が保持する「音片ID」みたいなリストに対して、駅側の案内装置が保持している実際の音声ファイルの内容（のハッシュ値）が、中央装置が思っているのと違うとか、何らかのアレでファイルが破損しているとか読み取りエラーだとか（げふ）、あまつさえ不正に書き換えられていないかとか（ゲフンゲフン）みたいな整合性のチェックを、仮には（複数の音片をディスクから読み取って、メモリー上で連結して、という意味で）放送文を組み立てるたびに行なうとかって、ないんですかねぇ。…その発想はなかった！（※やーいピーマンにもできる基本情報っ。）
※秒数が同じで非圧縮な音声ファイルが大量に…わあぃゾッとするね。（※個人の感想です。）
https://goo.gl/maps/KZpzMZtXU9s
https://goo.gl/maps/g2pk2oSZbKL2
https://goo.gl/maps/4aG2S7FPV892
https://goo.gl/maps/Xx55SWDmeA32
すごーい！（棒読み）…じゃなくて、ピコーン！ 銀座料金所に行きたいかーっ！！（もっと違）
・「基本情報技術者試験（レベル２）シラバス」
https://www.jitec.ipa.go.jp/1_13download/syllabus_fe_ver4_0.pdf
> 整列・併合・探索のアルゴリズム
> ハッシュ表探索法
> 暗号技術
> ハッシュ関数（SHA-256 ほか）
ゆっくり！ …じゃなくて、「ファイルの変更を検出するためにハッシュ値」みたいなのはレベル1だとおっしゃいますかっ。…なんと、レベル1からレベル4の各試験のシラバスに、そういう意味でハッシュ値を使う話は出てきませんでしたと申し添えます。ま、ファイルシステムみたいなのはOSなんですよね。OSを勉強しないでプログラミング言語だけ勉強していいんですかっ。（棒読み）
・（個人のページ）「Linux でファイルの変更を検出する(inotify/fanotify)」 | 