  |
はてなキーワード: CDDBとは
家にCDがあるんだけど、
100円でCD買ったんだけど、
どうせ音声データを取り出すなら、いい音質で聴きたい
そういう人のために、
Linux だと、
Whipperという、高機能なリッピング用のパッケージがあるよ
でWhipperはすぐにインストールできるよ（Debian系のディストリビューションの場合）
Whipper ではいろいろなことができるけど、
whipper cd info
デフォルト設定だと、flacというファイル形式でデータを取り出すようになっているよ
アルバム名、曲名、アーティスト名とかのデータを付加したファイルを作ってくれるよ
珍しいCDとか古いCDだと、whipperがメタデータを見つけられないことがあるよ
その時はエラーメッセージが出て、MusicbrainzというサイトにCDを登録するようお勧めされるよ
MusicbrainzはフリーのCDメタデータのデータベースだよ
（エラーメッセージの下の方に、だいたい、CDDBというデータベースから見つかった、正しい情報が載っているよ、でもこれはそのままでは使えない）
表示されているMusicbrainzのURLをブラウザに貼り付けると、CDの登録画面に行くよ
膨大な情報の中から探しているCDをかなりの確度で探し出してくれるよ
登録が終わったら、もう一回
を実行するよ
そしたらメタデータがきれいに入った状態で音声データファイルが作成できるよ
これだけ
Whipper は読み取りエラーを最小にして、
CDから忠実に音声データを取り出すことを優先して作られてるから、
気長に待とう
ChatGPTとシェルスクリプトを使って、自分でメタデータを一括入力する方法があるよ
それはまた別の機会に
この、指摘してるっぽい増田はそもそもCDDBのこと理解してなくない？
使ったことあるのかね
CDDBにはボランティア運営のデータベース（複数ある。英語メインとか、日本語メインとか、中国語メインとか）と、
企業運営のGracenoteがあってこっちは利用にライセンスが必要
カーナビに使われてるのはGracenote
Gracenoteに関しては、原盤メーカーが曲名データを登録できるようになってるけど
当然登録しないメーカーもいるので、その場合も含めてユーザーがデータ登録可能になってる
だから昔はそうだったでしょって。
立ち上げ時はユーザベース、ボランティアベース、営利企業の運営に以降した後も最新のCDはすぐには反映されなくて、ユーザが買ったCD自分で入力してた、ってググればいくらでも出てくるじゃん。
それぞれ違う人が「あの時はこうだった」って証言してて、Gracenoteのホームページにも記載があったのを、お前ただ根拠無く否定してるだけじゃん。
「"CD情報の入力が"ユーザのボランティアだった」って言ってるのを「"CDDBの運営が"ボランティア」っていいかえるのはなんなの？
CDDBとのやりとりは、CDDB搭載したアプリを使ってればだいたい分かるよ
読み込めないデータが多いわけよ
あと、マニアが入力してるから声優グループだと全員入力してたりして
多分カーナビのデータだと入力可能量オーバーしちゃうと思うんだよね
（ID3タグは規格によって登録可能な文字量とか文字種類が違う）
多分カーナビのテストした人がそこらへんしらない＋メジャーなCDでしかテストしてないせいで
エラー吐くんじゃないだろうか
詳しい説明と追記をありがとう。CDDBとの通信は問題ではなく、データの内容によってはカーナビ側が対処できない問題と理解した。
追記の説明を読む限りは、トヨタはプリウス増田のクレームに都度対処していたということだろうか。
http://anond.hatelabo.jp/20170505165338
CDDBの管理体制に問題があるから原因ではないかと挙げられたわけではない。
昔はデータが完備されていなかった。現在でも全てのデータが完備されているわけではない。データ空白がエラーに関与している可能性が指摘されただけだ。
カーナビがデータを処理できない問題ではないか、と原因を推測しようと議論している増田たちがいるだけだ。
トヨタの対応がなぜここまで悪化したのか、実際には何が起きていたのか、プリウス増田はどのように対応されるべきであったかを模索しているだけだ。
CDDBについての主張はわかった。それでは、増田の厳密な定義ではプリウス増田のプリウス（のカーナビ）では何が起こったと考えられるのだ？
増田の主張としては初歩的な間違いをしているような「素人」相手には説明できない、という判断か？
カーナビを利用する側に専門知識があるとは限らない。専門知識がないとわからない仕組みでカーナビが動作しているが、トラブルの解明も専門知識なしには理解が難しい。
専門知識がある増田にとってはどうしてわからないんだと歯がゆいことだろう。だが、専門知識のある技術者が直接サポートすれば解消する問題でもなさそうなのだ。
現に増田は知識を披露するだけで、プリウス増田へは目もくれていない。
自説を述べるべきでは？
http://anond.hatelabo.jp/20170506092022
これお前が言ってるだけだよね？
最初っから、「昔はユーザの入力がメインだった」しか言ってないと思うんだけど、お前こそ根拠レスで１人で相手の言い分捏造して「それは違う」って言い張ってるだけじゃん。
特に聞かないCDでも、そのアーティストの曲を全部保有するために借りたりする
いやだから昔の話でしょ？
もともとのCDDBは誰でも使えて誰でも登録できるサービスで、運営が企業に移ったあともしばらくは、少なくとも日本語CDはユーザ側が多くを入力してたよ？
俺も何枚か入力したよ？
2009年時点でも、iTunesにタイトルが表示されない増田がごねてるし、その頃のGracenoteのFAQには
http://anond.hatelabo.jp/20090420031928
とあった。
中のひとがきた、ありがとう。CDDBとのやりとりでコケる現象と理解してよさそうだ。この理解で合ってる？
この説明であれば、プリウス増田のプリウス（のカーナビ）が単独で通信障害を発生しているといえるが、プリウス増田が想定していたような全プリウス（のカーナビ）に関わる通信障害は発生していない可能性があると考えていいのか。トヨタの説明もおかしくないし、プリウス増田の怒りもおかしくない。
中のひとがきた、ありがとう。CDDBとのやりとりでコケる現象と理解してよさそうだ。この理解で合ってる？
この説明であれば、プリウス増田のプリウス（のカーナビ）が単独で通信障害を発生しているといえるが、プリウス増田が想定していたような全プリウス（のカーナビ）に関わる通信障害は発生していない可能性があると考えていいのか。トヨタの説明もおかしくないし、プリウス増田の怒りもおかしくない。
３行にまとめた
昔々、CDDBにデータがないCDのデータを読み込もうとすると、エラーメッセージが返ってきてめんどうだった
増田の状態は昔々の体験に似ているから、問題はCDDBにあるんじゃないの？
http://anond.hatelabo.jp/20170502233806 について、
実際に民生品のオーディオ機器用のソフトウェアを開発している中の人が推測するよ。
・通信は正しくできていることが多いと思う
・取得した内容が、その車載器で扱うとおかしなことになるデータで、そのせいで途中で処理が中断してしまい、「情報を取得できません」と表示されている。
というような感じだと思う。
車載器で扱うとおかしなことになるデータは、たとえば、アーティスト名がやたら長いとか、機器を使うときに想定していなかった文字が使われているとか、そういう感じのやつだ。
ある時Gracenoteのデータベースがバージョンアップしたか、元増田が録音した新たなCDにそれに該当するような曲が含まれていたために、そのような現象が発生してしまったのではないか。
それ以降も、その曲がHDDに残っている限り、その曲のデータも含めて取得しようとして、失敗する。
(CDDBが有志によって作られているから云々などの話は今回の件にはおそらく関係ない。それだったらそれ以外の曲のタイトルは正しく取得できるはずだからだ)
だから、もし元増田が「通信障害やメンテナンスなどで利用できない状況になってないか？」ということだけを伝えていると、問題の本質にたどり着かずにメーカ側としてもそのタイミングでの通信がどうだったか、通信する部分のソフトウェアに問題がないか、についての確認ばかりやって、的外れな回答ばかりになってしまうんだ。
そして最近、その問題になるデータが何だったのかがわかったんじゃないかな。なのでセンター側で特定の機種向けにデータを送るところで問題のないデータに変換して送るような対応を入れて、それで問題が解消したんじゃないか。まあ他の原因があるかもしれないけど。
開発側としては、問題が発生する直前に録音したCDが何だったのかが、一番知りたい情報だった。その頃の曲データをいくつか消していって、問題が解決するかどうか確認してほしかったところだ。そしてもし本当にそれが原因だったら、ソフトウェアにバグがあったということになる。開発者としては申し訳ないと思っている。
(追記)
http://anond.hatelabo.jp/20170506041735
原文読んでる？
3か月くらい経つと解消されて
翌年また起こるんだってば
あ、本当だね。じゃあ毎年ダメなデータがあって、それに対してデータ側でパッチ当ててたのかもしれない。
数日して「詳しく調べたら通信障害が発覚してたとの事です。復旧したようなので確認して下さい」と連絡が来た。
その連絡後に試してみると、問題なく使えるようになった。
この2行を読めてなかったか長文読んでる途中に忘れてしまったかのどちらかだった…。
この長文で現象を説明されたら僕もとんちんかんな回答をしてしまいそうで怖い。
(この文章は別にいいと思うけど、不具合報告のときには簡潔かつ主観や勝手な想像を交えずにお願いします…
ただどれくらい怒っているとか困っているとかについても、こちらとしては知りたいので、不具合の現象部分とは別に分けて教えてくれると嬉しいです)
(追記2)
上記の推測はあくまで推測でしかないし僕はトヨタのサービスはよくわかってないので全然違うかもしれないです。
http://anond.hatelabo.jp/20170505214607
上記の推測では、やりとりではコケてないと思っていて、そのCDDBから得たデータを録音データにセットするところで失敗して変なことになるんじゃないかなってことです。
http://anond.hatelabo.jp/20170506135000
特定のデータが悪影響を及ぼしていて、そのデータへのパッチで対応できるならそれが一番リスクが少ないから、初動としてはそうするんじゃないかと思います。
今回たまたまイケてる技術者が対応に当たって、現象が発生するパターンをロジカルに確定することができて、いい感じに(今後追加されるデータも含めて)対応できた、という流れかと思っています。何度も書くが、これも部分的な情報からの推測でしかないです。
2006年のプリウスのオーディオシステム、2005年11月1日のマイナーチェンジで追加されたものなので、開発は2002年ごろから。その頃は僕は車載機器を開発してなかったからよく知らないけど、当時の電子機器のソフトウェアはWindows2000でしか動かないような開発環境で作られていたりしていて、いまそれを修正するのは大変に困難を伴うと思う。だからクライアント機器側で発生した問題をサーバ側の対応で暫定的にあ解消させる、というのはよく見かける光景だけど、サーバ側の労力がどのようなものだったかは僕にはよくわかっていないです。
CDDBにはGracenoteのような企業が運営するものとfreedbのような有志によるものが存在する
増田が考えてるのはfreedbでトヨタのような企業が使うのは当然企業運営のCDDBだろう
https://ja.wikipedia.org/wiki/CDDB
少なくとも問題としている増田は、数年前にCDDBでデータのないCDについては自分で入力したデータを提供したと書いている。他の増田の指摘にも、入力はユーザーの労力によるところがあるとあげられている。Wikipediaの記述ではソースとして不満かもしれないが、仕組みとしてはユーザーの提供データに頼る部分があると記載されている。
CDDBの運営企業の認識する実態は異なるのだろうか？もしかして、業界の実情に詳しい方で、CDDBを擁護されたい向きだろうか？
カーナビからCDDBへのデータ取得の問題である可能性についてのお考えを頂戴できると、元の増田にとっても幸甚ではなかろうか。これほど熱心な利用者も少ないだろう。
2006年のプリウス搭載カーナビってどこのメーカー品なんだろうか。
トヨタ社員の対応も問題だけど、知識がないと分からないよなぁ。
だけどこういった事を末端のものにも教育する必要は絶対にある。
1.搭載されたナビの問題
CDDBの情報空白エラー説が挙がってるけど、元増田の言う通りであればそれはおかしくないか。
エラーが出た際は直近1年分のCDすべてが有名無名関係なく読み込めず、解決後はすべて読み込めるという。
元増田の音楽趣味が実は超マイナーで毎度数十枚一括処理でもされてるのかよ。
それも違う！障害発生時は、時間も曜日も関係なく、何日間も全く取得できない状況が続くんだよ！
すると、３月後半になって急に取得できるようになった。もちろん全てのＣＤで。
