Bansheeバグ覚え書き

Bansheeのバグをいくつか追いかけてみた。以下は覚え書き。

1. Bug 324353: トラック情報のダイアログに表示されるビットレートが正しくない

   ビットレートは普通は160KBあたりなのだが、ヒトケタの数字になってしまっている、という問題。パッチを書いてみた。ビットレートを計算する際にTimeSpanクラスのSecondsプロパティを参照しているが、このプロパティはトータルの秒数を保持するものではない。TotalSecondsプロパティを見るのが正しい。それと、ビットレートをキロビット単位に変換する際に1000で割っている、という問題もあった。

2. Bug 325725: メニューがローカライズされない

   メニューバーやメニュー項目のラベルのほとんどが英語のままになってしまう。日本語ファイルの問題だ、といったん閉じられたのだが、明らかにおかしいのであれこれ試してみた。起動時にGUIを生成する際の順番が間違っているような感じ。Bansheeはメニュー項目をグローバル変数で保持していて、それをGUIの生成前に初期化している。しかしGUIを生成してからでないとローカライズされたラベルを正しく読み込めないようだ。

3. Bug 325428: MP3ファイルのアーティスト名や曲名が文字化けすることがある

   MP3のID3v1型のタグには文字コードの情報は入っていない。アーティスト名や曲名は基本的にはUTF-8で入っているのだが、Shift-JISで入っていることもある。Shift-JISの場合は文字化けする。

   amaroKでは、ID3v1のタグはShift-JISとして読み込む、というように設定できる。しかしこの方法は明らかに不十分だ。そうするとUTF-8で書かれているデータが全部文字化けしてしまう。日本語、韓国語、中国語、ロシア語などが混在しているケースにも対応できない。設定するなら曲ごとでなければならない。

   BansheeはSQLiteで各ファイルの情報を保持していて、アーティスト名や曲名をMP3ファイルから独立に編集して保存できる。文字化けが起こったらそこだけ直せば問題ない。ただ、指定したフォルダをライブラリにインポートする際、文字コードを後から一つ一つ直すのは大変かもしれない。インポートの際に文字コードを指定できるようにするべきか。さらにMP3ファイル自体を書き換えて全データをUTF8にしてしまえば完璧。

4. Bug 326291: 現在の再生位置を示す数字がおかしい

   GStreamerを再生エンジンとして使っている場合、現在の再生位置(再生した時間)が正しく表示されない。GStreamerが提供しているgst_element_query()というAPIが常に同じ値を返してしまう。

   Banshee 0.10.2のリリースビルドをrootで動かすと正しく動作する。同じビルドを私のアカウントで動かすとダメ。最新のソースコードをビルドするとrootでもダメ。なにかの設定が影響していると思うのだが、まだわからない。

ほかにインストールされていないBansheeを起動できない、アクセラレータが効かない、という問題も発見。前者は簡単な問題なのでパッチを出した。後者は機能自体が完全に脱落しているようだ。

Comments

1. Posted by っき   2006年02月13日 10:15

Bansheeはまだ触ってないのですが、ちょっと気になったのでコメントします。
＞それと、ビットレートをキロビット単位に変換する際に1000で割っている、という問題もあった。
例えば、MP3で128kbpsなら、それは128000bpsのはずなんですが、1024で割るのが正しいというのはどこから得た情報でしょうか？
演奏時間とファイルサイズから得られた値を実測して正しくなかったという話であれば、原因として考えられるのは、
・ID3タグやLAMEタグ(今はMP3Infoタグでしたっけ？)等のメタデータが含まれている。
・エンコードの際にパディングが適切に挿入されなかった。
等ではないかと思われます。
128kbpsが128000bpsである根拠については、良いポインタが見つからなかったので、必要であれば、後で探してまたコメントします。

2. Posted by kazhik   2006年02月13日 23:13

あらためて調べてみました。たしかに1kbpsは1000bpsですね。御指摘ありがとうございます。

http://e-words.jp/w/kbps.html

問題のパッチにとっては1000か1024かはどうでもいいので、近いうちに書き直します。