wa2c's Weblog

2015-12-19 Ver. 2.5.5
– シークバーまたは早送り・巻戻しボタンの上下スライドによるシーク量調整機能追加
– ドロワーメニューの内容が表示されない問題を修正
– プロパティ読込でエラーとなる問題修正
– タグが読込まれない場合がある問題修正

2015-12-19 Ver. 2.5.6, 2.5.7
– シーク処理の問題を修正

Ver. 2.5.5

シークバーまたは早送り・巻戻しボタンの上下スライドによるシーク量調整機能追加

このバージョンより、シークバーをタップした際に上下に三角形のアイコンが表示されます。シークバーを押したまま、タップした指を上または下にスライドさせると、シークバーの移動量が調整できます。上方向で移動量が少なく、下方向で移動量が大きくなります。シークバーの移動を微調整したい場合や、シークバーの横が長すぎて一気に移動させたい場合等にご利用ください。iPhoneにも同様の機能があるそうですが（向きは逆らしいですが）、使った事ないのでよく知りません。
なお、早送り/巻戻しボタンも同様に、上方向で速度減、下方向で速度増となります。

ドロワーメニューの内容が表示されない問題を修正

ドロワーメニューの内容が、特定のタイミングで表示されない場合があるバグを修正しました。

プロパティ読込でエラーとなる問題修正

メディアのプロパティが正しく読込まれず、エラーとなる問題を修正しました。

タグが読込まれない場合がある問題修正

タグが正しく読込まれない場合がある問題を修正しました。

Ver. 2.5.6, 2.5.7

シーク処理の問題を修正

追加したシークバーの上下方向の処理で、エラーとなる場合や正しく処理が行われない場合がある問題を修正しました。修正は2回入って、2回バージョンが上がってます。

2015-12-25 Ver. 2.6.0
– デバイス切断・接続イベント処理見直し、各種問題修正
– スピーカー出力時のイベントを追加
– プロパティタブのスクロール位置を保存する処理追加
– プロパティタブの情報が多重登録される問題修正

 Ver. 2.6.0

デバイス切断・接続イベント処理見直し、各種問題修正

Bluetoothと接続/切断、イヤホンの接続/切断を行った際に、再生を停止する/音量を下げる等の処理を行うことができますが、この辺の処理が正しく機能していなかったため、修正しました。
特に、音量が正しく戻らず音量が下がった状態で確定してしまう問題があったため、その修正が主です。

 

スピーカー出力時のイベントを追加

元々、Bluetoothの切断イベントやイヤホンの切断イベントで再生停止等を行うことができましたが、どうにもこのイベントが受け取れず、再生がそのまま継続してしまう場合がある、という問題がありました。 これの原因がよく分かっていないのですが、イベントが受け取れない以上は、こちらで対策の打ちようがありません。
そのため、「音声が外部出力に切り替わるタイミング」イベントでも同様の処理を行えるようにしました。世の中にある数多くのプレイヤーはこのイベントを使う場合が多いようですね。Medolyでは現状、両方のイベントで動作を設定することができます。ちょっとややこしいですが、デフォルトの状態では再生停止が設定されているので、特に問題がなければそのままで良いです。

プロパティタブのスクロール位置を保存する処理追加

プロパティタブのリストのスクロールの位置を保存するようにしました。 メディアが切り替わったり、アプリを再起動した際に、一々先頭に戻るのが煩わしかったからです。

プロパティタブの情報が多重登録される問題修正

プロパティタブの中に情報が多重に登録されてしまうバグがあったため、その修正です。タブの処理周りを修正していたため、その時に少し処理を間違っていました。

更新情報の記載をずっとサボってたので、一気に書きます。

2015-11-11 Ver. 2.4.5
– プラグインのメニューをドロワー化
– プラグインダイアログレイアウト見直し
– 一部文字化けタグでアプリが落ちる問題修正
– イベント無効化設定の処理修正
– 共通パラメータのライブラリ化
– 参照ライブラリ見直し

2015-11-14 Ver. 2.4.6
– プラグインのイベント有効設定をドロワーに移動
– 歌詞フォントサイズの最大を40spまで拡大
– 再生キューの自動スクロール設定廃止
– 再生キューのスクロール処理調整
– レイアウト変更時に急激に歌詞がスクロールがする問題修正
– 同期歌詞の長押しでスクロール位置がずれる問題修正

Ver. 2.4.5

プラグインのメニューをドロワー化

メイン画面にドロワーメニューを付けました。
ドロワーメニューというのは、画面の左端から画面に覆い被さるように出てくるメニューのことです（通常は左端というだけで、別に左端とは限りませんが）。メニューを表示するための操作は3種類あります。どれで表示しても一緒です。ユーザビリティ上どれでも実行できるというだけです。

• 再生キューリストを表示した状態から、再生キューを右スワイプする。
• 左上のアプリアイコンをタップする。
• 端末画面の左の縁から画面の内側に向けて右スワイプする。

以前はポップアップメニューから表示していたプラグインのメニュー を、このドロワーメニューに置換えました。併せて、このメニュー上から手動実行アクションが実行できるようになっています。
以前から、プラグインの手動実行アクションを実行するために、左上ポップアップメニューからダイアログを表示→コマンド実行、という手順が煩わしかったので、ドロワーメニューから簡単に実行できるようにしてみた次第。
ちなみに、ドロワーを追加するためにAndroidのライブラリを追加したのですが、これのせいでAPKのサイズが1MBぐらい増えて、約1.5倍になってます。インストール後のサイズもだいぶ増えてます。何てこった。

プラグインダイアログレイアウト見直し

ドロワーメニュー追加に伴い、プラグインのダイアログレイアウトを色々見直しています。

一部文字化けタグでアプリが落ちる問題修正

Android標準のタグ読み取り処理においてアプリが落ちる問題があったため、この機能を使用しないようにしました。この問題は、例外でキャッチできずに強制終了されてしまうため、こちらで対策しようがありませんでした。
なお、現在タグの読み取りには jaudiotagger を使用しています。（古いAndroidで動作しないため、最新バージョンではありません）

イベント無効化設定の処理修正

プラグインのイベント無効化チェックに関する処理の修正です。

共通パラメータのライブラリ化

Medolyおよびプラグイン等で共通にしようしている固定値やパラメータについて、ライブラリ化しました。ライブラリはaar形式です。
ちなみに、こうしてサラッと書いていますが、プラグイン周りを共通化するために結構大掛かりな変更が入ってます。

参照ライブラリ見直し

参照ライブラリについての設定を見直しました。
一部ローカルファイルで参照していたものを、Gladleで取得するようにしたとか、そういう感じです。

Ver. 2.4.6

プラグインのイベント有効設定をドロワーに移動

従来、設定画面にあったプラグインイベントの有効/無効設定をドロワーメニューに移動させました。

歌詞フォントサイズの最大を40spまで拡大

歌詞のフォントサイズは30spまでを上限としてたのですが、大きめの画面で使うとちょっと小さいので、40spまでを上限とするようにしました。感覚的には50spぐらいあってもいいかもしれませんが、とりあえずこの辺で様子見です。

再生キューの自動スクロール設定廃止
再生キューのスクロール処理調整

今まで、再生キューのスクロールについては、楽曲が選択された際に再生キューを選択曲までスクロールさせるかどうかのチェックボックスがありました。
これは、例えば楽曲を選んでるときに曲が切り替わって勝手にスクロールされたら困るし、逆に再生キュー画面を表示したままの状態で曲の切替えでスクロールが追従してくれないと困る、といった微妙なところを調整するための設定だったのですが、正直こんなもの一々使わなかったので廃止しました。
その代わり、以下のような動作をさせるようにしています。

• 再生キューが手動スクロール中の場合は勝手にスクロールしない。
• 再生キュー画面にタッチ中の場合は勝手にスクロールしない。
• それ以外の場合は曲が切り替わった際にその曲までスクロールする。

 まぁそんな感じで、勝手にスクロールさせるかさせないかの微妙なところを自動的に判断するようにしてみた次第です。

 

レイアウト変更時に急激に歌詞がスクロールがする問題修正

表示タブの内容をダブルタップして画面を最大化した時など、歌詞が急激にスクロールする問題がありました。これは、レイアウトが切り替わった際に内部的な座標が変更され、歌詞スクロール位置にとんでもない座標が指定されてしまうことが原因でした。
スクロール座標の調整を行って修正しています。

同期歌詞の長押しでスクロール位置がずれる問題修正

歌詞を長押しした際にシークする機能を付けましたが、その辺りのバグ修正です。

2015-12-04 Ver. 2.5.0
– ドロワーメニューにプレイリスト追加
– 歌詞の空白の取り扱い変更
– 内蔵歌詞読み込み処理修正
– MP3の文字コード判定処理修正
– スクロール処理調整
– プロパティ情報修正
他修正

2015-12-08 Ver. 2.5.1
– JoyHackフォーマット対応
– UNSYNCED LYRICSフィールド対応

Ver. 2.5.0

ドロワーメニューにプレイリスト追加

Ver. 2.4.5でプラグイン向けに追加したドロワーメニューですが、ここにさらにプラグイン選択メニューを追加しました。プレイリスト/プラグインの切替えは上部のタブから行います。
現状でもプレイリストは再生キューメニューの「プレイリスト操作」から選択できていました。ここに更に、ドロワーメニューからプレイリストを選択できるようにした理由ですが、ユーザビリティ上の理由によるものです。
従来は、「再生キュー選択→再生キューメニュー→プレイリスト操作→プレイリストにチェック→開く」という流れの操作を行う必要がありましたが、今回は「ドロワーメニュー開く→プレイリスト→プレイリスト選択」という簡易な操作になります。また、初期設定ではプレイリストを選択した時点で再生キューが更新され、楽曲の再生を開始します。これによって「プレイリストを切り替えて音楽を聞く」という操作が極めて簡易になります。
また、以前も書きましたが私は車のダッシュボードに携帯のクレードルを置いて、そこで操作を行うようにしています。そういう状況では、簡単な操作でプレイリストを切り替えられるというのは、非常に重要な要素です。実際、これを追加したことで再生キューの入れ替えが簡単になり、長距離ドライブも苦にならなくなった、という個人的に極めて高い実効性（？）を示しています。

歌詞の空白の取り扱い変更

同期歌詞において、今までは単純にテキストの行の頭にタイムタグが存在していたらそれは歌詞の行、それ以外は歌詞の行ではない、という判定をしていました。ところが、同期歌詞においては単純な空行を歌詞の空行として扱うことを期待している場合があります。その場合、当然本来期待されている空行が詰まってしまい。 文字の詰まった見辛い歌詞表示となってしまいます。そんなわけで、単純な空行を歌詞の空行として扱うようにしてみました。
 …などと簡単に書いていますが、 実はこれ、単純に空行を歌詞の一部として扱うだけでは済みませんでした。行単位の同期歌詞は別に何の問題もありません。問題は文字単位の同期歌詞です。通常は、単純に最後に再生された歌詞行の末尾の時間を空行の頭に割り当てれば良いです。ただ、文字単位の同期歌詞においては、前回の行が進行中に次の行に移動し、複数行が同時に進行する状態があり得ます。その間に空行が挟まった場合、通常と異なる処理が必要になってきます。まぁ色々割愛しますが、思った以上に面倒臭かったです、これ。

内蔵歌詞読み込み処理修正

 ユーザ様より、読み取れない内蔵歌詞があるとのご意見をいただきましたので、それに合わせて修正してみました。具体的に言うと、 foobar2000のプラグインで編集した歌詞とのことでした。この編集によって、MP3に通常の「USLT」タグではなく、「UNSYNCEDLYRICS」というタグに歌詞が書込まれた状態となっていた様です。ここで終わったと思ったのですが、実は終わっていませんでした…。次のバージョンへ続く。

MP3の文字コード判定処理修正

MP3が文字化けするというユーザ様の報告があったため、文字コード判定を修正しました。
個人的なMP3の文字コードについての文句は、この辺をどうぞ。
この変更によって、UTF-16とShift_JISが混在しているタグでも何とか読み取れるようになっています。内部的な処理としては、文字コードが「ISO-8859-1」に設定されたタグを全部掻き集めて、タグの内容を一つのバイト配列に固めて、自動文字コード判定ライブラリに送り込むという力業を行っています。ユーザ様のタグは読み取れたそうですが、正直、これ以上はお手上げです。
ちなみに、 文字コード混在タグの場合、プロパティの文字コードには「UTF-16(改行)Shift_JIS」みたいな感じで2種類の文字コードが入っています。
なお、そうなっているMP3は全部UTF-16に置換える努力をした方がいいです。ここまで頑張ってタグを読み取ってくれるアプリばかりではないゆえ…。

スクロール処理調整

再生キューのスクロールの処理を少し調整しました。
画面の表示タイミングで自動スクロールが実行されないなどの問題があったのですが、タイミングを調整して実行されやすくしました。これを確実にスクロールさせる方法がよく分からない…。

プロパティ情報修正

プロパティタブの中に表示する情報を少し変更しています。著作権タグに対応しました。

Ver. 2.5.1

JoyHackフォーマット対応

JoyHackというのは、 カラオケを行うためのフリーソフト及びそのシステムです。「女医ハック」という名前の方が通りが良いようです。カラオケJoysoundのHyperJoy システムを利用していたためにそういう名前がついています。昔はカラオケに入る曲も少なく、自分の歌いたい曲がなかなかなかったため、自前で曲を用意して歌うという文化があったようです（自分はあまり知りませんが…）。その際、HyperJoyという機種において、ビデオ入力/音声入力の端子があり、利用には最適だったようです。
ちなみに、今となってはカラオケには液晶TVが配置され、当たり前のようにHDMI端子が存在しているため、ビデオ/音声入力はかなり簡単になっています。というか、スマートフォンからHDMI出力もできるので、Medolyを用いた簡易カラオケも出来たりします。まぁそもそも、今はカラオケの曲もかなり充実しているため、そこまでする必要はないかもしれませんが…。
前置きが長くなりましたが、Joyhackで用いられている歌詞データも、文字単位の同期歌詞データとなるので、適当にフォーマット見て対応させてみました。読み取り処理はかなり適当なので、もしかしたら正しく読み取れないかもしれません。また、Joyhackは歌詞データに音楽ファイルのファイル名が記述され、歌詞ファイルが主・音楽ファイルが従、という位置付けなのですが、Medolyでは他の歌詞ファイルと同様に、音楽ファイルに対して同名の歌詞ファイルを読み取る、という処理になっています。ちなみに、拡張子は.txtです。

UNSYNCED LYRICSフィールド対応

前回のバージョンで内蔵歌詞のタグ「UNSYNCEDLYRICS」に対応しましたが、どうやら「UNSYNCED LYRICS」（スペースの有無の違い）が正しいタグの名前だったようで、こちらにも対応いさせました。
ちなみに、「UNSYNCEDLYRICS」はMp3taｇによってタグが付与される場合があるようですが、詳細はよく分かりません。とりあえず、現状ではどちらでも読み取れると思います。

現在、Ver.2.7.0をリリースしていますが、再生キューにメディアが登録できない事象の報告を受けています。
現在原因を調査中ですが、事象の再現ができず、原因がよく分かっていません。
同様の事象が発生した場合、申し訳ありませんが下記URLから旧バージョンのAPKをダウンロードしてインストールしていただけると助かります。

http://wa2c.com/android/medoly/apk/

Android★SQUARE:■Medoly ~ プラグインで機能強化できる純国産音楽プレイヤー

昨年の話ですが、Android★SQUARE様の上記ページでMedolyについてご紹介いただきました。ありがとうございます。
ここまで実直な感想を書いていただいたのは初めてなので、嬉しいやら気恥ずかしいやらといった感じです。

私が全くヘルプや取説を書かないばっかりに、余計な手を患わせてしまい申し訳ありません…。いつか書かねばと思いながら、今に至るまで全く書いてない有様です。この辺は今後の改善として考えていきたいです。

そもそもこのツール自体、自分自身が使うことを想定して作っていて、自分が良ければの精神で作ってしまっているため、どうしてもそういった第三者に向けてのフォローが疎かになってしまいます。これはデメリットに見えますが、一方で継続的な開発のモチベーションを保ちやすいというメリットにもなっています。
他者のために手間をかけて開発モチベーションが落ちて全く開発されなくなるか、手間を掛けずに自分が作りたいものを作って開発モチベーションを保ち続けるか、という2択のどちらが良いかという話です。私は後者を選択したいです。

画面が無愛想なのも同じ理由です。個人的に、あまり外見的なデザインとかに拘りがなくて、違和感がない程度に統一されていればいいや、ぐらいの感覚です。

ちなみに、有料にしたり広告を入れたりといった金銭のやり取りについては今のところさっぱり考えていません。金銭的な報酬は私のモチベーションとあまり結びつかないですし、なにより面倒臭いしがらみが出来て開発しにくくなるのが嫌です。金銭のやり取りが発生すると色んな責任が生じてくるのは避けられません。面倒な責任は負いたくないし、面倒臭いユーザーに対して「それなら使わなくていいです」と堂々と言ってのけたい、というのが正直なところです。

今後も継続的な開発を行っていきたいと考えていますので、ご理解いただけると幸いです。
今は少し忙しいので時間がとれてないですが、プラグインの機能は少し強化していきたいです。

音楽ファイル内蔵歌詞について、開発していく中で分かったことについて簡単に触れておきます。
多くの音楽ファイルは、ファイルの中に歌詞を内蔵することができます。内蔵歌詞は大抵の場合、非同期歌詞（つまり、ただのテキスト）となっていますが、同期歌詞を内蔵する場合もあります。歌詞データは音楽ファイルの中にタグ（タグフィールド）として埋め込まれています。
ところで、一口にタグと言っても様々なフォーマットが存在します。これは、音楽ファイル固有の場合もありますし、異なる音楽ファイル間で共通して用いられる場合もあります。タグのフォーマットとファイル形式の対応を以下に示します。

• ID3:MP3標準のタグフォーマット。ID3v1とID3v2があるが、通常はID3v2を使用する。
  対応形式: MP3(.mp3), AAC(.aac)
• Lyrics3: MP3のタグフォーマット。ID3と互換性は無い。v1とv2がある。”Shiang-shiang’s Lyrics Displayer”というWinamp の歌詞表示プラグインが埋め込むタグが元となっている…らしい。
  対応形式: MP3(.mp3)
• Vorbis Comment: Vorbis音楽ファイル標準のタグフォーマット。
  対応形式: Ogg Vorbis(.ogg), Flac(.flac)
• iTunes MP4: AppleのソフトウェアがM4Aファイルに付加するタグフォーマット。
  対応形式: AAC(.m4a)
• ASF (Windows Media): Windows Media形式で使用されるタグフォーマット。
  対応形式: ASF(.asf), WMA(.wma)
• APE tag: Monkey’s Audio音楽ファイルで使用されるタグフォーマット。様々な音楽ファイルに内蔵されている場合がある。
  対応形式: Monkey’s Audio(.ape/.mac), MP3(.mp3), WavPack(.wv)
• RIFF: 共通コンテナフォーマット。この構造を持つファイル形式は、.wavや.aviなどがある。本来は様々なデータを入れる汎用フォーマットだが、音楽ファイルはWAVE形式が一般的。
  対応形式: Wave(.wav)(PCM音源の他、MP3等が格納される場合もある)

これらのタグフォーマットは、各タグフィールド毎に識別子(ID, フィールド名)を持っています。この識別子はタグフォーマット毎にバラバラです。フォーマット間の識別子の対応付けについては、音楽情報データベースの大手であるMusicBrainz.orgのTag Mappingを参考にするのが良いと思います。これが正式というわけではないですが、特にこだわりが無い限りはこれに従うのが無難です。各種アプリケーションやライブラリも、これを基準にして作られている可能性があります。それ以外には、Mp3tagのTag field mappingsなども参考になるでしょう。
これらを踏まえた上で、各タグフォーマットについて内蔵歌詞の識別子を以下に示します。

• ID3v2: USLT(非同期, ID3v2.2はULT), SYLT(同期, ID3v2.2はSLT)
  [ID3v1は無し]
• Lyrics3v2: LYR (同期)
  [Lyrics3v1は識別子無し]
• Vorbis Comment: LYRICS (非同期)
• iTunes MP4: ©lyr (非同期)
• ASF: WM/Lyrics (非同期)
• APE tag: Lyrics (非同期)
• RIFF: ILYC (非同期)
  [公式のものではなく、主に日本のユーザ間で用いられていた模様]

これらに加え、アプリケーションが独自に識別子を与えて、タグフィールドを定義する場合があります。これらは、形式問わず様々な音楽ファイルに内蔵される可能性があります。とりあえず認識しているアプリケーション及び識別子には、以下のような物があります。（間違っているかもしれませんが…。）

MedolyのVer.1.0.0を最初にリリースしたのが2013/12/08なので、Medolyをリリースしておおよそ2年ほど経過しました。

現在のバージョンは2.5.1、内部バージョンは75（つまり、74回バージョンアップしてる）。

現在の端末ベースのインストール数は600超ぐらい。ユーザ数ベースの総インストール数は2500ぐらい。

インストール端末数推移

 

総インストール数推移

驚くほど安定した増加推移で、あまり面白味はないです。
 
作りたい機能はまだ色々ありますが、現在は少し開発時間を減らしてるので、ペースは落ちます

目下の大きな目標としては、内部的に使用しているMediaPlayerオブジェクトをffmpegに置換えたいです。ただ、やっぱりちょっと面倒なので一体いつになることやら…という感じで。

これからもぼちぼち開発を続けていきたいと思いますので、今後ともお使いいただければ幸いです。

Medoly開発において気になったので、ちょっとだけMP3のタグの話。

MP3は汎用性は高いですが、そのタグの仕様が大変に厄介です。MP3が登場して20年ぐらい経ってると思いますが、未だに安定せず、頻繁に問題事を持ち込んでくれます。
 
まず、MP3のタグはID3タグと呼ばれる標準の規格が存在し、ID3.org において規格が管理されています。
ID3には大きく分けて、ID3v1と、ID3v2が存在します。細かく分けると、 ID3v1はID3v1と、ID3v1.1があり、ID3v2にはID3v2.2, ID3v2.3, ID3v2.4があります。ID3v1とID3v2は共存できますが、ID3v1は、今となっては使い物にならないので忘れましょう。
問題は ID3v2です。ID3v2.2, ID3v2.3, ID3v2.4は互いに互換性はありません。とりあえず一番新しいバージョンを使えばいいと思われそうですが、そうは問屋が卸しません。ID3v2.4はハードウェアやソフトウェアが対応していない事も多々あり、Windows Media PlayerやiTunesといった主要なソフトウェアは、少し前まで対応していませんでした。ID3v2.4は、文字コードにUTF-8が使えるようになったり、年だけでなく年月日が入力できるようになったりしてるといったいくつか変更はありますが、v2.3とそんなに大差はないです。現在、最も普及しているのはv2.3なので、それにしておくのが無難です。
 
そして、更に問題となるのが文字コード。 ID3v2タグには、文字コードを設定することができます。…が、文字コードとして設定できるのは、「ISO-8859-1」と「UTF-16」だけです。（v2.4はあまり使わないので、UTF-8が設定できることは忘れましょう。設定してもいいですが、多分読めないプレイヤー多数です。Medolyは読めるはずです。）

日本語を扱う上で、文字コードに「ISO-8859-1」を設定した上で、Shift_JISを入力する場面が多々あります。私から言いたい事は『金輪際そんなタグは入力しないでください』ということです。ISO-8859-1はあくまでも英語等のアルファベット文字を使う言語圏で使われる文字コードです。日本語はサポートされていません。「ISO-8859-1」と設定されているのに日本語が読めるのは、ISO-8859-1と設定した上で、Shift_JISの文字を入力しているからです。何故そのような事が慣例化しているかと言えば、MP3の黎明期、ID3v2のサポートが少なかったり、Unicodeのサポートが満足に行われていなかった時代があり、日本においては日本語の表示はこちらの方が安定していたためです。
ところが、MP3の仕様上はあくまでもISO-8859-1です。海外のソフトウェアでは日本語を読み込むことはまずできませんし、多言語が混在していた場合、それが日本語なのか、あるいは別言語なのか判別する手段がありません。
そのため今現代においては、全ての言語をサポートするUTF-16で入力した方が、確実に文字を読み込むことができます。MP3にはタグの文字コードがUTF-16と判別させる方法が存在するため、読み間違いが起こりません。

…が、事がそう単純にはいかない点もあります。ID3v2のタグの規格上、このタグの文字コードは「タグ毎に」設定することが出来てしまいます。すなわち、タイトルがISO-8859-1、アーティスト名がUTF-16となっているMP3が存在する可能性がある、という事です。例えば、作りが雑なタグ編集ソフトの場合、タグを編集した際にそのタグだけに勝手に文字コードを設定してしまうという場合もあるでしょう。

ところで、MedolyではShift_JISで入力された文字も判別できていますが、これは文字コード判別ライブラリを使って強制的に文字コードを判別させているためで
す。文字コードの判別処理というは、通常かなり力業な処理が行われており、特定の文字コードにしか登場しないコードパターンの出現で判別したり、といった
事を行います。すなわち、文字数が少なければ判定を誤る可能性が高い、ということです。タイトルだけ、アルバム名だけ、といった文字数程度では判別が失敗する可能性が高いです。ちなみにMedolyでは現状、タイトル、アーティスト名、アルバム名の文字を繋げて文字コードを判別させています。

つまり、UTF-16とISO-8859-1で入力された多言語がタグに混在したMP3は、正直こちらではお手上げ状態です。Meodlyでは、現状そのようなMP3は想定していません。最初に取得したタグに応じて残り全部の文字コードを決定しています（この処理は少し変更するかもしれませんが）。何せ文字コードの自動判定がアテにならないため、それがShift_JISなのか、はたまた中国語なのか韓国語なのか、こちらで判別する手段がないためです。
ちなみに、Medolyでは本当に何も判定できない場合は、最終的に端末使用言語に応じて文字コードを分岐させています。日本語ならShift_JISになります。

そんな感じで長々と書いてみましたが、MP3のタグの読み込み（特に文字化け）については、こちらで対応できる事に限界があります。Medolyは恐らく英語圏のソフトよりは、文字が読み取られる可能性が高いですが、それでも完璧というわけにはいきません。
文字コードについていくつかご質問やご意見を頂く場合がありますが、個人的には「質問を投げるぐらいなら、さっさと自分でタグをID3v2.3、UTF-16に直してしまった方が遙かに早い」と思ってます。M4A等の別の音楽形式使うのも有りです。

最後に言いたい事まとめ。
『MP3のタグはさっさと全部ID3v2.3のUTF-16に直すこと。話はそれから。』
『MP3タグの文字コードはタグ個別に設定できる。使用するタグ編集ソフトが吐き出す文字コードをきちんと確認。英語圏のソフトはISO-8859-1のタグとか平気で吐き出す場合がある。』
『MP3のタグ仕様は本当にクソ』

唐突ですが、最近車を買いました。1ヶ月ぐらい前の話です。というか、携帯を変えたのとほぼ同時期です。車の維持費の代わりに、携帯の回線費用を抑えたとも言います。
購入動機は、すぐ移動できる足が欲しかったのと、色々試したいことがあったためです。

もちろん、車内の音楽再生にはMedolyを使用しているのですが、その際以下のような使い方をしています。

ダッシュボードの上にクレードルを貼り付けて、その上に携帯を置く感じになってます。クレードルは少し緩衝材を挟んで、車体が揺れても携帯が落ちないようにしています。
この配置により、歌詞を見たり、再生キューから曲を選択するといった簡単な操作をスムーズに行うことができたりします。

そんな環境のため、以降の更新ではこの環境を想定した変更が行われるかもしれません。具体的には、

・クレードル設置時のアクション設定
・全画面表示状態での操作改善
・Bluetoothとの連携強化

等です。ちなみに、最近の更新でBluetoothのレイテンシ設定を追加したり、ボタンの長押しリピートを追加したのは、この環境のためです。

こうした利用について、もっとこうした方が良い等のアイデアを頂けると嬉しいです。