| No. | 手順 | 備考 | ||
|---|---|---|---|---|
| 1 | CDからWAVへ変換 |
音源データには何も手を加えない事が大前提なので、WAVでリッピングします。私的にFLACは無しです。 リッパーとしては、メタデータのデータベースも豊富なiTunesを使います。 CDのエラー補間はPioneer PureReadで完璧に排除できることと、GAP等の再現性は不要なのでExact Audio Copyは使わないことにしました。 しかしWAVの場合、メタデータを曲ファイル自身に埋め込むことはできません。 精々ファイル名自体にTrack No.と曲タイトル、アルバム名やアーティスト名などを羅列する位しか方法はありません。 それでも後から一曲ずつタイトルを手入力する手間を考えれば随分楽ではあります。 |
||
| 2 | WAVからDSFへ変換 |
今のところ、KORG Audio Gateのお世話になってます。 Audio GateではDSFへの変換の際に「アルバムタイトル」、「アーティスト名」等は一括してメタデータに登録できます。 残念ながらファイル毎に変更する必要がある「曲タイトル」は一曲ずつ手入力するしか方法が無い様です。 Audio Gateにはメタデータ中の曲タイトルをファイル名(ソング名)にコピーする機能はあります。 しかし変換元はWAVデータなので、そもそもファイルにメタデータは存在せず、この機能は使えません。 これとは逆方向の、ファイル名をメタデータに取り込む機能があればよかったのに。 もっとも、この機能があったとしても、 致命的な問題(2)にぶち当たることに違いはありません。 |
||
| 3 | アドホックな運用 |
一曲ずつタイトル名を手入力するのだけは避けたいので、「運用でカバー」することにします。 曲タイトルはそのままファイル名になっているので、足りない情報として、「ARTIST(アーティスト名)」「ALBUM(アルバム名)」だけを手入力することにします。 この処理は選択したファイル全てに一括適用されるので、アルバム1枚に一回入力するだけで済みます。 HDP-R10では、「アルバム」毎や、「アーティスト」毎にインデックスが作成されますので、特定のアルバムを再生したい時にはインデックスからすぐに探せるはずです。便利ですね〜 |
||
| 4 | まぁ、なんとかなる 問題(1) |
ところが、この方法だとHDP-R10で再生した際、アーティスト名は「unknown」になってしまいます。 当然、「アーティスト」毎のインデックスでも「unknown」に分類されてしまいます。 結論として、 これは正しい仕様だと思います。おそらく問題は無いでしょう。 これは明らかなバグと思われます。 |
||
| 画面1 |
まぁなんとかなる状態 TIT2フレームが無いと、ファイル名をタイトル代わりに表示してくれる様です。 その配慮があるのに... もっと大事な所でミスってます。 |
|
||
| 5 | 問題(1)への対処方法(1) |
この状態でも、HDP-R10では「フォルダ」を選択して再生する事ができるので、アーティスト毎にフォルダを分けてあれば、あまり問題はありませんでした。運用でカバーできる範囲です。 但し、現状では「フォルダ」からUSBストレージが見れない問題もあり、「アーティスト」一覧のunknownに大量に分類されてしまうのは気分悪いですね。。 |
||
| 5 | 問題(1)への対処方法(2) |
TIT2さえ入っていれば場当たり的ではありますが、バグを回避できて、ちゃんとアーティスト名も認識される様です。 面倒なのを諦めてAudio Gateで1曲ずつ曲タイトルを手入力すれば良いのでしょう。 でも、それは嫌!です。 また、実際には、たとえ手入力しても後述する致命的な問題(2)にぶち当たることになります。 |
||
| 5 | 問題(1)への対処方法(3) もっと面倒な手段に出る！ |
問題はTIT2が無いことだけと、この時点では考えていました。 あとからTIT2だけを追加する方法は何があるのでしょうか。 もちろん、Audio Gateで手入力＆DSFを再度作成と言うのはNGです。 理想は、ファイル名に曲タイトルが入っているのだから、ファイル名をTIT2として埋め込めればそれだけでOKなのです。 でも、DSFのメタフレームを編集出来る様なツールなんて、そもそも見つかりません。 ... 無いなら作ってしまえ。 |
||
| 6 | 一番面倒だった所なのにさらっと省略 |
SONYのDSF File Format Specificationや、ID3.orgの仕様書とニラメッコしてでっち上げました。 2つのLSB(Least Significant ByteとLeast Significant Bit)が混在してたり、 4byte(32bit)の各最上位bitを使わずに28bit長の数値データとして扱うなど、 相互変換ロジック作るのに頭が痛くなる仕様でしたが、それはまぁともかく、ID3v2の仕様書は、書き方に大きな問題ありと思う。 それもまぁどうでもいいことですが。 自作ツールはファイル名から.dsfを削除したものをTIT2フレームにして、DSFファイルに追加するだけのものです。 当然、DSFヘッダーのファイルサイズや、ID3v2ヘッダーのメタフレームサイズ等も書き換える必要があります。 まずは、英語(ISO-8859-1)のみのファイルでテストし、無事、ここまでは成功しました。 但し、Ubuntu/linux上で作ったソフトなので、Windowsでは使えません。 (私がWindowsでソフト作れないだけですが...) この時点でAudio GateからHDP-R10へのワークフローにlinuxまで必要になります。こりゃダメでしょうね。 |
||
| 画面2 |
英語のみのDSFファイルに自作ツール適用 ファイル名をそのままTIT2へ埋め込んでます。 期待通りの結果です。 |
|
||
| 7 | 自作ツールの日本語対応 |
最初から日本語対応まで盛り込むのは、とっても面倒な気がしていたので、まずは英語のみで全体の流れを作りました。 ISO-8859-1については特に問題なく、期待通りに動きます。ここまでは上出来です。 さて、日本語のエンコードは何でしょう?と調べてみたら... DSFファイルフォーマットでは、ID3v2.3をメタフレームデータとして使用することが規程されています。 さらにID3v2.3規格では、下記の記述があります。
...もう少し分かりやすい言葉に言い換えると、
と言う、どっちにしても目の回りそうな文字符号化方式です。 UTF-8だったらUbuntuからは何の変換もせずにそのまま使えるのに。 まぁ、なんとかUTF-8からUTF16BOM+LEへの変換もできました。 しかし、このテストにより致命的な問題(2)が発覚します。 |
||
| 8 | 致命的な 問題(2) |
日本語のタイトルを埋め込んだDSFファイルをHDP-R10で表示させると、日本語文字列の後にゴミが出てしまいました。 本来表示されるべき文字列の後ろに、いわゆる豆腐や、日本語ではない文字がずらずらと出る状態です。 当然、自作ソフトのバグを疑ました。文字列の長さは上述の28bit演算が絡むので、ロジック自体が間違っている可能性もとっても大きいです。自信無いし。 しかし生成されたデータをダンプして確認しても、問題はなさそうです。 原因が判らず、Audio Gate単体でTITLEフィールドを日本語で記述したDSFファイルを作り、表示してみると... やっぱりゴミがでます。 但し、TITLE(TIT2)フィールドが存在しないDSFファイルだと、アーティスト名はunknownになってしまいますが、アルバムタイトルは化けません。 しかし、そのDSFファイルにAudio GateでTITLEを追加すると、途端にタイトル、アルバムタイトル、アーティスト名全てにゴミがつきます。 どちらにしてもダメダメですね。 |
||
| 画面3 |
致命的な問題画面。 AudioGateでTITLEフィールドへ曲名を入れた状態。 どうしようもない。 |
|
||
| 9 | 問題(2)への対処方法 |
無理ですね。 さすがにHD Music Playerをリバースエンジニアリングする気力は無いです。 。。。タグ情報に日本語を使わない。と言う選択肢もあるか。。。 |
タイトルの後ろにスペースを山の様につければ、パッと表示されるエリアにはゴミが見えません。
表示だけの問題ならこれでごまかせるのですが、アーティスト名にもゴミが付きます。
その結果、ゴミのついた状態で「アーティスト」一覧へ登録されてしまいます。
これはもう、許容範囲を越えるダメなレベルですね。
DSFファイルへの対応は、iBassoでも初めての事だと思います。先行した姉妹機のDX100ではサポートしてませんので。
更にDSFファイル自体、SACDのフォーマットとは言え、一般的に使われてるとは言い難いフォーマットです。
これらを考えると、バグが発生する事自体はやむを得ませんが...やはり商品として市場に出すレベルには達していないと言わざるを得ません。
今回は、iBassoでは無く、ヒビノに問い合わせをしてみました。
まだ回答はありません。
気を取り直して最初の話の続きです。
こんなことをテストしていて、WindowsPCからHDP-R10のMicroSDにDSFファイルのコピーをじゃんじゃかしてました。
その中で、1回だけ、ファイル転送途中でフリーズが発生しました。
何がいつもと違ったかと言うと、ACアダプタを使わずに内蔵バッテリ駆動状態でのコピーだった事です。
コピーするファイル自体は何度も使っているファイルなので(中味のデータはTIT2とか若干違いますが)特異点にはなり得ません。
つまり、HDP-R10のバッテリ駆動は、MicroSDへの書き込みオペレーションにすら影響が出る程、 余裕が無いのではないか?
と推測しています。
公式にはサポートされてないMicroSDXC(64GB)使ってるからって可能性は...無いよなぁ。
その状態でUSBメモリまで動作させるのは、やっぱりキツいのかもしれませんね。
と言う事でした。
戻る