「パリティ」を含む日記 RSS

はてなキーワード: パリティとは

2020-03-14

PCR検査偽陽性偽陰性バーコード理解すると判りやすい件

未だに偽陽性偽陰性の違いが判らずに「偽陽性医療崩壊」と言ってる阿呆ブクマカがたくさんいるので説明するよ~

 

PCR検査遺伝子検査だけど全部は調べない。

DNARNA(新型コロナRNA)の一部を拡大する薬剤処理をして光学的か電子的に読めるようにする。

次にその塩基配列の一部がウィルス塩基配列と一致するか?を見るテストなのな。

で、この読み取りってバーコードの読み取りに似てるわけよ。

バーコード記号って黒太線、黒細線、白太線、白細線で4つ。

DNA場合はアデニン、グアニン、チミン、シトシンなんだが、RNAウィルス場合はチミンが無くて代わりにウラシルが入るので4元素。なっ?バーコードそっくりだろ?

 

ここでバーコードリーダーエラーについて考えよう。

偽陰性に該当するエラーっていうのは

 

レーザーバーコードに当たっていない。

→これは検体中にウィルスが含まれて居ないのに相当する。ウィルスが増殖してる箇所から取らないで免疫反応で出てるだけの鼻水や痰を採っちゃったってケース。一番多い。

 

レーザーが斜めに当たって半分しか読めてない

→これはRNA目標箇所の真ん中で切れてしまったケース。採取された細胞から漏出したアミラーゼウィルスRNAを切断した、免疫細胞ウィルスと戦って破壊した、薬剤処理の失敗など。

 

リーダーの焦点位置に合ってない

→薬剤処理で上手く増幅されなかったケースにあたる。

 

バーコード読み取りでこれらはエラー音すらしない。単に読めないだけ。でも一番多いのがこのエラー音無エラーだよな。

 

 

では偽陽性に当たるエラーってなんだろうか?

 

・赤ランプが付いてピピピ!とビープ音がなる。

→これは読み取った数値が化けてしまったケースだ。12345の数字が12245とかに読み取りされた。DNAならGACTTがGCATTになってるようなモノだ。

バーコードの一番後ろはパリティコードになってて数値の和の下一桁などが記述されている。簡易計算してパリティーと合わないので「数値が化けてる」とエラーが出る。

 

それじゃこれが偽陽性なのか?

いや、これも偽陰性だ。

偽陽性って言うのは「カルビーかっぱえびせん85G」のバーコードとの照合を行っている時にこのエラーが起きて、その数値化けの結果が「カルビーかっぱえびせん85G」と一致する状態だ。

こんな事滅多にある訳無いって判るだろ。

スーパーで違う商品買った事になってた事って一度だってあるか?

 

発生するとすれば参照している「カルビーかっぱえびせん85G」コードが短すぎる時だな。

例えばバーコード先頭2桁は国コード、左半分はカンパニーコードになってる。

ここで先頭2桁を参照すれば日本製品は全部「カルビーかっぱえびせん85G」と判定されるし左半分を指定すればカルビー製品は全て「かっぱえびせん85G」となってしまう。

他のウィルス細菌にも含まれる箇所を指定してしまったら起こりうるがこれは検査員がボケなだけだ。

または増幅薬剤の指定おかしくて肝心なところでのマッチングテストが出来ていない。

 

こういう訳で偽陰性は大量に起こりうる。

特に採取が上手くないとダメで、どこでウィルス繁殖するか、免疫系が殺した廃物がどこに流れるかが分かって無いといけない。

だが偽陽性は読み取りエラーの末にウィルスRNAの一部と合致するという奇跡エラーであるから滅多に起こりえない。

 

判りましたか

まぁこんな誤解してるブックバカーは一部だけどさ。ID:REVとかな。この人も劣化が激しいが15年前は斜に構えた姿勢が人気を博していたが、今本人が15年前のブクマと今の自分ブクマ比べても違いは判らんだろな。

だが15歳年下の脳が緩くなってない人間が読み比べたら如実に違いが判る。そういう状態だな。

2019-10-15

anond:20191015151319

字が汚くてパリティーって読めたんだよ

今日も気張って誤り検出してくれ

2019-09-09

anond:20190908235850

パリティチェックとかしてみたら?

 NTSFだとセクタ問題じゃないから昔と同じ方法が通じるか知らないけど、クラスタ破損とかで書き込めないってのはよく聞いたよ。

俺は怒りでも喜びでもクラウドで二重バックアップしてるからセーブできなくてもあんまり不都合は感じないな。

2019-08-04

anond:20190804221338

さよう。パリコレとはパリティカル・コレクトネスであり、フランス首都マロニエの立ち並ぶ花の都ポリである

2018-03-01

anond:20180301000842

そこは、超冗長にするのよ。RAID6じゃ足りないから、もっとパリティ的なノードを確保。

障害性もその分バッチリよ。

どうしても不足したら、wakeonlanで立ち上げるとか。

サーバパソコン数台とで、どっちが電力消費いかな。場合によりパソコン数台を常時起動しても良さそう。

2017-08-15

Windows 10記憶プール

かつての情報では「シンプル記憶域は1回作ったらドライブ交換等一切不可」だったけど、

今はわりと融通が利くようで、GUIから「削除の準備」して待てば安全に取り外せる。

ドライブが死んだ後だと当然無理だし、うっかりライトバックキャッシュありで記憶域を

作成してしまうとSSDを0台にできないとか、いろいろ制限はあるみたいだけど。

これすげえ便利じゃね。容量がちょっと足りなければ小さいドライブで細かく増やすことが

できるし、ドライブ換装の際にデータをいったん別のドライブに移してという作業必要ない、

というか換装という概念がなくなる。

これまでファイルサーバで固定台数パリティしか使ってなかったけど、メインマシンでも

使ってみっか。

2017-03-11

今年で6年経った

http://anond.hatelabo.jp/20110602193012

この増田から6年か。

 

福島は未だに復興されてなくてもはや避難先に根付いてしまった人たちもいるらしい

震災直後では火の海になった気仙沼話題になったけど、こっちのほうは復興したのかな

って、調べてみたらインフラは概ね治ってきたみたいだけど産業震災前の60%程度しか復興していないみたい

http://www.pref.miyagi.jp/uploaded/attachment/608418.pdf

まああんだけの被害があったらそうそう治らないよね

 

原発の方は、東芝原発LNGに大博打を張って結局半導体産業日本から手放すという大失態をしたのが印象的だった

世界では再生可能エネルギーが続々とグリッドパリティを達成しているのに何たる惨状

しかネット社会ではこの状態になっても未だに「反原発放射脳疑似科学的」とか「再生可能エネルギーは役に立たない」とか悪評が目立つ

思うに最初反原発が今のしばき隊の連中に見つかって変な色がついたのが悪かったんだろうな

あれさえなければもっと受け入れられた選択肢だと思ったんだけど

2016-04-19

カセットテープを大量にデジタル化した時のメモ

色々あって大量のカセットテープデジタル化した時のメモ

なお音質は特段こだわりはなく、数を取り込んだ話です。

再生機器や録音機器

再生機器NR付きの方が後々楽(後述)。

録音形式はある程度の音質で取り込んでしまえば後で加工してしまえばいいのであまり考えない。

音質云々は割愛

後処理

曲分割

ある意味一番時間がかかるのがここ。

NR付きの再生機器ならテープ録音状態によっては機械的に分割処理かけてしまえば簡単に綺麗に分けられる。

ただこれが使えないテープ場合手動で分けることになるがこの場合大変。

このとき必要なのは時間だが、古いと曲名だけで時間は意外と載ってなかったりする。

最近Google先生が気を利かしてくれて、そこそこ有名だとアルバム名で検索すると曲時間が簡単に出てきたりする。

この情報経由で動画等を検索できる便利な情報だが、この表示されている時間情報動画時間から自動生成されているらしく偶に変な情報があったりする。

タグ付け

これが面倒かというとそこそこ有名な曲ならば簡単だったりする。

対象の大半がCD化もされているような音源だったので(ならデジタル化する必要は?とは言わないで)Gracenoteのデータベースを引っ張ってくれば簡単。

今は既存音源からでも検索がかけられるので、適当アルバム単位検索すれば大抵引っかかる。

自分場合この作業にはMedia Goを使っているが、そのままだと引っかからない場合でもアーティスト名やアルバム名のタグ情報を入れて再検索をすればまず存在する。

言語で出ている作品場合、別言語タグ情報に書き換えて検索すると引っかかったりもする。

またGoogle Play Music場合、あちらでデータがない曲で一度間違ったタグ情報で上げると記録されるのでタグ情報を書き換えてアップロードしてもそのままでは反映されないので注意。

ノーマライズ

後でバッチで一度に処理すれば良いという考えで保存用に関しては特にこの処理はしない。

保存等

現代HDDBDなら、FLAC可逆圧縮でもかけておけば一本辺り200MB~500MB程度と大した容量にならないので普段用と別に保存してても大して逼迫しない。

これが今デジタル化しようとしたきっかけの一つ。

保護にはBDならMultiPar等でパリティを付けて保存、ディスクの保管はBD対応した不繊布でもいいが数百本取り込んでも数枚程度なので転写が嫌ならハードケースで保存してもスペースには問題ない。

BDは今のベアディスクタイプですら10年近く経った規格でそれなりに成熟していると考えられるのと、かなり減ってきたがまだ地方だと相次いだメーカー撤退による投げ売りが偶にあるのでネットで買うより処分品狙いで買ったほうが安かったりする。(狙い目はDVDレンタル店)

流れ作業で行う場合

データとともにカセットテープのケースやインデックスカード画像データを保管しておくとアルバム名等を確認する際に現物をいちいち確認する手間がなくなるので捗る

またミスで再取り込みになった時も画像を手掛かりに現物ピックアップできる。

カセットテープ本体はCISスキャナしかない場合取り込みは困難なのでインデックスカードだけでも取り込んでおくだけでもいいが、その場合音声データを取り込む前に本体のラベルインデックスカードが正しい組になっているか確認したほうがいい。

ただ単純なインデックスカード場合スキャナドライバの性能によるがそこまで面倒ではないものの、特別意匠をこらされている場合この作業は凄まじく面倒になる。

結論

自分のような勿体ない症のような人以外は特別もの以外はカセットテープデジタル化は止めておいたほうがいい。

2015-02-07

IT業界マネジメント

PGは、まず見積もりを依頼されます。この時ほとんどの場合要求仕様書が無いか、あっても伝聞で情報が欠落もしくはエラーを起こしています。残念ながらエラー訂正機構は装備されていません。CRC、せめてパリティでも入っていればちょっとは違うかもしれません。期待出来ませんが。

ここでプロジェクトマネージャー(又は管理者経営者等。以後PMと称する)から「最速でやった場合」「割り込みが入らない場合」「君がやった場合」or「部署内で最高ランクPGがやった場合」「仕様変更が無い場合」という条件が付きます

底辺PG諸君。ここでこの言葉額面通りに受け取ってはいけません。

「【最速で】3ヶ月かかります

と答えたらPMは【普通に】3ヶ月の工程工程表に書き、見積書に3人月分の金額を書きます。そしてこれは後述する危険と隣り合わせとなります

この危険経験したPGは大抵リスクを込みで【黙って】見積もりを伝えます

しかPMはお見通しです。「高い」「そんなに時間がかかるわけが無い」と言い、受け付けません。何故なら実はPMの頭の中では既に「3ヶ月」なのです。PMは追い込むために見積もりの詳細を聞いてきます

ここで素直に「リスク込み」と答えてはいけません。既にPMは前述の前提条件を述べているからです。無下に却下されます

そう、PMは「PGの口から言わせたい」のです。

戦いたいPGかつPMが同じ会社であれば「後学のためにPMの詳細見積もりをお聞かせ下さい」と聞いてみるのも良いでしょう。ただし確実に印象悪化は避けられません。PM発注元の場合は禁句です。まずキレます。そのまま発注されない事もあるでしょう。発注されなかった事を喜びましょう。

なぜキレるか。それは簡単です。「明確で論理的理由が無いから」です。理由が無い上に実は既に予算が決まっており、それを超える事は許されません。予算を超えた見積もりはPMさら上層部経営から怒られる事を意味するからです。理由が無いから理由PGに考えさせているのです。PM仕事をした気にさせるのも底辺PGの役目です。

予算を超えた見積もりはあり得ませんので、答えは「がんばりますしか残りません。しかPMはそれすらもPGの口から言わせたいのです。でもよく考えて下さい。あなたの脳はオーバークロック出来ますか?

底辺PGが出来る事は、PMユーザーが分からないように期間と予算を加算するくらいです。

一応、市場原理が働くため、安い方がいいに決まっています。金払いのいいユーザー元請けってのはあんまり無いです。そして金払いの悪い所ほど後々してやられますので、最初予算の付け方でどういう所かが大体予測出来ます

そんなわけで、予算と期間に品質と内容は関わりがありません。もちろん企業の使命として、安くて良い品を、安くても利益を、は追求してしかるべきなのですが、日本場合と金額が比例するのは極一部。IT業では基本的に、安くて良い品を出来るだけ高速に、がモットーです。受注しなければ会社がやっていけないのは分かりますが、「安さ」だけしか売り物に出来ない会社は、IT会社として失格でしょう。

かくして、短納期予算プロジェクトが組まれるわけです。そのPM理論からすると、高速バス東京から新大阪へ行く方が、新幹線のぞみ指定席グリーン車で行くより高く、書留速達郵便より普通郵便の方が値段が高い、という事になりますが。質、時間価格の何がIT業と違うんでしょうか。

実のところ発注や作業開始は遅れている事が多く、納期に間に合わせるには発注前に作業を開始せざるを得ない場合が8割ほどです。実はここにも罠が仕掛けられています

作業に取りかかろうとようやく出てきた仕様書を見ると、見積もり時の時と変わっていたり、追加されていたり、未だに仕様が無い場合ほとんどです。

「こんなものをこんな期間で出来やしない!」と憤慨してはいけません。なぜなら

「君自身見積もったんだよね」

という答えが返ってくるだけです。PM見積もらない理由がここです。PM見積もりを聞いてはいけない理由がここです。これは後々まで効いてきますので注意が必要です。「前提条件と違う」と反論するのは無駄です。PMはそれは忘れています。そもそも考えて発言していないので口が勝手脊髄反射で言った事であり脳は関知していないのかもしれません。PMにとって最重要な事は「PG自身が言った事」です。そう、工程表にも議事録にも「3ヶ月」という数字のみが記載され、いわゆる「リスク」は何処にも書かれて残っていません。

PMユーザー絶対リスクや前提条件を書き残しません。それがこの業界伝統ある慣習だからです。

ここで言った言わないの不毛な戦いをしてもいいのですが、確実に査定は最低です。もしプロジェクトから外されたらそれは喜びましょう。

管理者経営陣等からは「やる前に出来ない言うな。やってから言え」と怒られます。残念ながらこれも真に受けてはいけません。

設計、構築など作業をしている間もどんどん仕様変更・追加は流れ込みます

必然的工程遅延は避けられない事態となっていきます

PM工程進捗を把握しているのでは無く、PGが【自ら】工程表報告書に纏めます。遅延していれば遅延の理由も書き、挽回策があればそれも書きますしかPG個人が取れる挽回策などたかがしれています。と言うよりそれが分かっていれば遅延などしません。他の策は既に実行済みなので、挽回策には「残業休日出勤」くらいしか書く事が残りません。しかしこれは現実にこれしか書く必要がありません。なぜならPMはこれ以外の挽回策は理解不能からです。

仮に報告をしても「早すぎる。もっとやってみてから」「がんばれ」という答えが返ってくる事でしょう。

遅れを放置するPMもいますが、許容範囲PMにもよりますがある程度遅れが見えてくるとPMから追求がやってくるようになります

「なぜこんなになるまで報告しなかった」

そう、報告出来る時期というのは非常に限られています。多分プロジェクト工程(今の例なら3ヶ月)の中の30分くらいです。それより早いと相手にされず、それよりも遅いと怒られます。報告時期を見誤らないのもPG業の技です。

実装が難しかったり、無理難題は多々あり、その上工程が遅延しているので、相談をしに行きますしかし、それは無駄です。

自分で考えろ」

自分で書いた工程表だろ」

「やってから言ってるんじゃねぇ。やる前に言え」

他似たような答えしか返ってきません。非常に非生産的です。理不尽です。時間無駄と考え報告・相談に行かないPGも多いとか。非生産的ですが、一応相談はしておきましょう。ただし時間は取られないように。

同僚やチーム員に相談してもいいのですが、昨今のプロジェクトは人員がスタンドアロンで動いています。したがって、隣の人やチーム員がが何をやっているのか知らない事が非常に多く、相談出来ない事も多いのです。PGメンタル病が多いのは実は理由がここにあると自分は思っています孤立感が半端無いのです。まぁ、元を追えば、そいういうチームを組む事、教育訓練しない事など、実は管理者経営者が「カイゼン」や「効率向上」を題目に目の前の超短期的コスト削減だけを考えている結果なので、PGとしては何も出来る事はありません。管理者経営者は中長期について考える必要が無いからです。なぜなら「その頃には自分は満額の退職金を貰って定年退職済み」だから

実のところ単独仕事をしていればいい、と言う事はあり得ません。同じプロジェクトの中から割り込みや、他のプロジェクト・部から割り込みは多々入ります

始めに言ったじゃん。どうにかして。というのは無駄です。覚えてないし、「会社員なら当たり前だ」という答えが返ってくるだけです。「15分だけ」「ちょっとだけ」が頻発しますが、塵も積もればなんとやら、です。ちなみにこの件は査定・人事評価には全く影響がありません。

相談すれば「午前中はこの仕事、午後はこの仕事、定時後はこの仕事をすれば並列同時が可能だ」とあたかも新発見超名案を出したかのように返されるのが落ちです。そう、1日が24時間しかない事は忘れ去られ、PG人間である事は忘れ去られ、思考の分断は効率を激しく低下させる事を知らないのです。

ここで断る勇気を持つの大事ですが、職場内の雰囲気は格段に悪化します。評価は「人でなし」「自分勝手」「自分本位」「冷たい」。これらの視線に耐えられるのなら断りましょう。こちらからすれば「自分時間を奪う方がよっぽど人でなしだ」と言い返したい気分です。

テスト工程も始まり、遅延が激しくなる上に、バグ発見されさらに遅延という状況が始まります

ソフトウェアである以上、バグが無いプログラムなんてのはあり得ないのでバグを出す事自体は不可避です。

ところがPMは激しく怒り出します。バグ発見PMに一報が行きPMが怒られるからです。

底辺PGバグを出す毎にこっぴどく怒られます。中には仕様変更事実PGまで伝わっていないのにバグ扱いされる事も多々あります

バグを出すと修正テスト、再発防止策の考案などの厄介事が増えます

再発防止策は通常「どうやったら自動的にそうならないか」を考えますが、あまりに根幹すぎるので、底辺PG身分では権限が無く、出来る事が限られます。そしてPM理解出来る策を考えねばなりません。結果「テストを増やす」「チェックシートを作る」とかになりがちです。しまいには「チェックシートのチェックシートを作る」などという意味不明現象に陥ったプロジェクトを何度も見ています

厳しく、それは厳しく怒られる上に、チームの前でさらし者にされる事、人格否定される事も多々あるので、PGバグを出さないように、見つけても出来るだけ極秘裏に解決しようとします。

これが最近流行

「恐怖駆動型開発」

というもので、日本場合ほとんどがこの開発手法をとられていると聞きます。この開発手法書籍になっておらず、書籍としてよく売られているのはアジャイルな開発手法の本が多いです。知識として持っているのはいいと思いますが、役に立たないと思いますねぇ、恐怖駆動型開発の前には。まわりの人間も恐怖に巻き込まれないようにするため、どんどんスタンドアロン化が加速します。

その上、バグを隠すようになり、バグが出るようなテストを避けるようになるため、短期的に収束しているようにみえます。だから効果絶大と見るようです。リリースしてからが楽しみですね。

PMが空想から覚め、もう救いようが無くなった事が事実認識出来るようになった時、ようやく、2度目の相談・報告時期が訪れます。ただし、PMの第1声は「どうしたらいい?」です。そんな事が分かっているのなら実行済みなので、黙っているしかありません。

するとPMは「何人入れれば良い?」と聞いてきます意味が分かりません。IT業を労働集約産業勘違いしているのが未だに存在している事に驚きです。頭脳集約型の形態に人を入れて解決しようとはどういう脳をしているのか。一度解剖してみたいものです。多分、高校受験する中学3年生の受験者が100人まれ旧帝大入試合格すると考えているのでしょう。もしくは1Km走というのは1000人が一斉に1m踏み出せば1Km走った事と同じ記録である、と考えているのでしょう。

脳を電通で直結出来れば若干違うかもしれませんが、IT業の1+1は2では無く、良くて1.5。ましてやこれで増えていくのは3~4人までが限界でそれ以上は人を入れても上がらないどころか、マイナスになる事が常。

PGなら他のプロジェクト、他の部、他の会社に信頼出来るエース級のPGを何人か知っているかと思います。なのでついPMに「エース級を3人」等と提案しがちです。しかしこれは叶わぬ望みです。その提案に対する答えは「そんな事出来るわけないだろ」です。そりゃそうです。予算が無いのだから

結果、何だか良く分からない人員が多数集められます

自分仕事があるのに、何故かこの後から来た人員を纏めるうPMから指示が出ますPMが指示出来ないからです。破綻は間近です。いや、既に破綻しています

プログラムが出来上がっていく以上、バグをつぶす速度以上の割合バグを注入していく事になります

悪循環が始まっていますね。

「混乱しているプロジェクトに人を入れれば、なお混乱するだけ」

という有名な文を実感する事でしょう。なお、実感するのはPGだけであり、PMは実感出来ません。

この辺で思わぬ事態が発覚します。実は発注が遅れていた事です。

発注日以前にドキュメントがあっては監査にひっかかるため、今まで作ったドキュメントを作り直しをしなければならないという、まさに想定外事態です。ほとんどのドキュメントには作った日付や判子が押されているはずです。それを全部作り直しするのです。納期は間際です。これも納期までに間に合わさねばなりません。

PM(重ねて書くが、プロジェクトマネージャだけでなく管理者経営者も含む)が発狂し始めます。宛先は底辺PGです。

中には「お前を精神的に追い詰めるしか手がねーんだよ」とストレートに言ってくれるPMもいたりしますが、あまり出会った事は無いですね。

あの手この手精神的圧迫を始めます。圧迫すれば脳がオーバークロックして作業が進むと考えているからです。残念な事に、脳の別の部位がオーバークロックしてショートしてしまます

こういうプロジェクト経験し、運がいいのか実力なのか、生き残った人達SEとなり、いずれPMとなっていきます

不思議な事に日本では、PGが成長してSEに、SEが成長してPMに、とクラスチェンジするものだと考えられている会社が多のですが。

自分としては、座標軸のX,Y,Z軸の様にPG軸とSE軸とPM軸と全く異なるベクトルだと考えています。X軸の先にY軸Z軸があるわけでは無い、と。もちろん、軸に沿っているだけでは無く、他の軸のベクトルも併せ持つのもよいエンジニアでしょうし、ベクトルの方向を伸ばし続けるのもよいエンジニアでしょう。

ところが、クラスチェンジするものだと管理者経営者は思っているから、給与体系もPGSEPMとなっていたりします。この時代錯誤階級社会はどうにかならないものでしょうか。

自分PM否定しているわけではありません。いいPMの元でいい仕事をしたい、と思っているだけです。今までに何度かそういう良い経験をした事はあります。それは成功経験としてモチベーションを保つために必要な事なのです。

PG至上主義でもありません。分業形態として、SEPM必要不可欠だと思っています。ただ、PGを粗末に扱っておきながら高品質製品要求する風習・慣習が納得出来ないだけなのです。

2011-02-07

http://anond.hatelabo.jp/20110207130528

お前ほんと頭悪いな。

バグとかwwwマジ受けるww

つまり4850がバグってるって事?

ってか結局1920*1200*32bitまでを扱う場合シングルリンクで帯域は足りてる訳

そこでHDMIだろうがDVIだろうが差はない。

からお前の言う画質に差がない事をまず認めろ。

画質に差はないよな?お前の気のせいだよな?

ってか画質の話でなんでオーディオ

ちなみにエラー訂正とかは基本的にはデータリンク層の話だからぶっちゃけフォーマットは関係ないよ。

MPEGだろうが関係ないかwww

なんでアプリケーションレイヤーが関係してくるのかwww

CRCパリティをすり抜けたら複合化できないかぶっちゃけエラー訂正不可で表示されなくなるんだけどww

馬鹿が知れるだけからいい加減黙った方がいいよ。

http://anond.hatelabo.jp/20110207123957

横だけど、このあたりオーディオ界隈だと結構面白い話転がってるよね。

デジタル信号なのに、音質が変化するって大真面目に言う人が居て笑う。


デジタル信号は、一定以上の電圧が一定時間継続する事を1、それ以外を0と判定する方式で、これが1bit。

(電圧0を1と判定する場合もある、回路次第)

大概の場合、1単位データは32bitとか8bitとかなっていて、パリティチェックとかもするからアナログ的な変化はしないんだよね。

それが発生するということは、データそのものが書き換えられているってことでさ。

音質が変わるとすれば、「どの様にデータ改ざんすれば音がよくなるのか」という判定・修正技術確立しているという事で。

誤り補正スルーするしたら、それ、すごい技術だよね。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん