# かなり長くなったので、スレッド分けます。

mp3infp Unicode版 Ver.2.54h/u6を公開します。
http://homepage3.nifty.com/k-takata/tmp/mp3infp254h_u6.7z (1.6MB)

・非対応の ID3v2.2 フレームがあると、それ以降のフレームが読み込まれないのを修正
・ID3v2.2 と ID3v2.3 のフレーム ID 変換処理を変更
・iTunes 固有のコメントフレーム (iTunNORM, iTunSMPB, etc.) をスキップするように修正
　- コメントに 16進数文字列が表示されるのが解消された
　- コメントを書き換えたときに、iTunes のギャップレス再生や音量均一化などのためのデータが壊れないようになった
・ID3v2 の文字列読み込み処理を整理

以下で報告されていた問題が直っていると思います。
http://win32lab.com/bbs2/index.cgi?no=9519&pastlog=0002&act=past&mode=allread
http://win32lab.com/bbs2/index.cgi?no=9816&pastlog=0002&act=past&mode=allread

引き続き、きわめて実験的な版であり、致命的な不具合が含まれているかもしれません。必ずファイルのバックアップを取った上でお試しください。
特に今回は、ID3v2 まわりをかなり書き換えたので新たにバグが出ている可能性があります。

こんなに変更点が多いとansiも更新ですかね…

> こんなに変更点が多いとansiも更新ですかね…
可能ならばそうした方が良いとは思いますが、Unicode対応と今回の変更でId3tagv2.cppはかなり書き換えてしまいましたので、反映は多少大変かもしれません。
ところで、Id3tagv2.cppを見直していたところ、新たに2つばかり問題が見つかってしまいました。

1. 文字列エンコードを変更すると、mp3infpが対応していないフレームは、エンコード情報だけが変更され、中身は変更されないままとなり、不正なフレームになってしまう。
2. URLをWXXXフレームに格納する際、エンコード指定に関わらずISO-8859-1で格納しなければならないのに、エンコード指定に従って格納している。

というか,拡張子がついてしまうのの他はid3v2の修正だけな気がします.
というわけでu5とu6のdiffを採ればok.

u5はもう消してしまったのですね
なんとか残っていたg/u5とdiffを取りましたが、かなり長いですね(論理的にも)…

### Umm 場合によってはライセンス的に抵触するかもしれないですね(DataToCString()など)、もうANSI版は更新停止すべきかもしれません…

> u5はもう消してしまったのですね
あまりスペースがないもので・・・

> なんとか残っていたg/u5とdiffを取りましたが、かなり長いですね(論理的にも)…
g/u5 と h/u5 は、Id3tagv2.cpp についてはほとんど変更ありません。差分は h/u2 で変更した MakeTag() 内の拡張子の処理だけです。したがって、それ以外の差分が今回の変更分ということになります。

> g/u5 と h/u5 は、Id3tagv2.cpp についてはほとんど変更ありません。差分は h/u2 で変更した MakeTag() 内の拡張子の処理だけです。したがって、それ以外の差分が今回の変更分ということになります。
そうそう,h/u5とh/u6の差が余りにも大きいわけ.

> 1. 文字列エンコードを変更すると、mp3infpが対応していないフレームは、エンコード情報だけが変更され、中身は変更されないままとなり、不正なフレームになってしまう。
> 2. URLをWXXXフレームに格納する際、エンコード指定に関わらずISO-8859-1で格納しなければならないのに、エンコード指定に従って格納している。

これらを修正したmp3infp Unicode版 Ver.2.54h/u7を公開します。
http://homepage3.nifty.com/k-takata/tmp/mp3infp254h_u7.7z (1.6MB)

1.については、非対応のフレームはエンコードを変更しないようにしました。これにより、非対応のフレームを含むファイルの文字列エンコードを変更したときにフレームが不正になることは解消されますが、代わりに1つのファイルに複数のエンコードが混在することになります。

2.については、規格に合わせてURLは必ずISO-8859-1（実際にはSJIS）で書き込むようにしました。このため、h/u7でUTF-16を選択してURLを書き込むと、以前のバージョンでは正しく読めなくなってしまいます。
読み込み時は、基本的にISO-8859-1として読み込みますが、BOMがあればUTF-16として読み込みます。

> > 2. URLをWXXXフレームに格納する際、エンコード指定に関わらずISO-8859-1で格納しなければならないのに、エンコード指定に従って格納している。
> 2.については、規格に合わせてURLは必ずISO-8859-1（実際にはSJIS）で書き込むようにしました。このため、h/u7でUTF-16を選択してURLを書き込むと、以前のバージョンでは正しく読めなくなってしまいます。
> 読み込み時は、基本的にISO-8859-1として読み込みますが、BOMがあればUTF-16として読み込みます。

万が一非ASCII文字を入力された場合はすべてエスケープしないといけない気がします.
#2.54iはDataToCString()をどうするか未だに考え中.

> 万が一非ASCII文字を入力された場合はすべてエスケープしないといけない気がします.

どの文字コードと仮定してURLエンコードするかが問題です。

> どの文字コードと仮定してURLエンコードするかが問題です。
そうですね.

#各種ブラウザはどういう実装なんだろう.

> #各種ブラウザはどういう実装なんだろう.
IE や Firefox では、デフォルトでは UTF-8 として扱うようになっていますが、設定によりシステムのデフォルトの文字コードで扱うように変更可能です。

IE: UTF-8 の URL を送信する
Firefox: network.standard-url.encode-utf8

# 規格としては RFC 3986 で、UTF-8 として扱うように定められたらしいです。

Unicode版に、WAVEとAVIのタグが正常に書き込めないバグが見つかりました。
修正したmp3infp Unicode版 Ver.2.54h/u8を公開します。
http://homepage3.nifty.com/k-takata/tmp/mp3infp254h_u8.7z (1.6MB)

ついでに、WAVEにトラック番号を保存できるようにしてみました。
http://win32lab.com/bbs2/index.cgi?no=9106&pastlog=0002&act=past&mode=allread
AVIとRMP3もRIFFですが、今回は対応していません。

> 修正したmp3infp Unicode版 Ver.2.54h/u8を公開します。
> http://homepage3.nifty.com/k-takata/tmp/mp3infp254h_u8.7z (1.6MB)
mp3infp_ExportFunc.h の修正漏れがあったため、アーカイブを差し替えました。

いつも更新ありがとうございます。

Windows7(64bit)にmp3infp 2.54h/u8をインストールした状態で、
Cakewalk SONAR 8.5.1でエクスポートしたwavファイル(44.1kHz 16bit Stereo)のプロパティを開こうとすると、エクスプローラを巻き込んで落ちるようです。

> Cakewalk SONAR 8.5.1でエクスポートしたwavファイル(44.1kHz 16bit Stereo)のプロパティを開こうとすると、エクスプローラを巻き込んで落ちるようです。
ご報告ありがとうございます。
よろしければ現象の発生するwavファイルをいただけないでしょうか。
今回の現象は2.54h/u8で初めて発生した現象でしょうか。

> > Cakewalk SONAR 8.5.1でエクスポートしたwavファイル(44.1kHz 16bit Stereo)のプロパティを開こうとすると、エクスプローラを巻き込んで落ちるようです。
再現できるファイルがなかったため、ソースコードの確認を行いましたが、原因は特定できませんでした。
代わりに、別の問題が見つかったため修正しました。

http://homepage3.nifty.com/k-takata/tmp/mp3infp254h_u9.7z (1.6MB)
・GetFileSize64(), SetFilePointer64() が複数のファイルで定義されていたのを、
GlobalCommand.cpp/.h に集約、エラー処理を強化。
・WAV ファイルの 2GB 超過の判定が間違っていたのを修正。

mp3infp Unicode版 Ver.2.54h/u10を公開します。
http://homepage3.nifty.com/k-takata/tmp/mp3infp254h_u10.7z (1.6MB)

以下で報告されていた問題が直っていると思います。
http://win32lab.com/bbs2/index.cgi?no=9014&pastlog=0002&act=past&mode=allread

修正については以下の情報を参考にしました。
http://www.multimedia.cx/mp3extensions.txt
http://www.codeproject.com/KB/audio-video/mpegaudioinfo.aspx

mp3infp が更新され続けていることに感謝しているものの一人です。日頃から重宝しています。ありがとうございます。

mp3infp v2.54h/u9(mp3infp v2.54h/u10) インストール環境下(Win XP SP3)にて適切にファイル(.avi)の時間が正しく表示されない例があったため報告しておきます。念のため真空波動研Lite 090902(+真空波動研 090902c テスト版)にてファイル情報を確認したものをあげておきます。

test.avi

640x480 12Bit XviD 1.1.0 Final 29.97fps 426359f 1003.58kb/s
MPEG1-LayerIII 48.00kHz 96.00kb/s CBR Stereo
INFOTAG
[RIFF(AVI2.0)] 03:57:06.178 (14226.178sec) / 1,963,935,468Bytes

真空波動研Lite 090902 / DLL 091108

真空波動研Lite にて 03:57:06.178 (14226.178sec) となっていたファイルが、
mp3infp v2.54h/u9(mp3infp v2.54h/u10) にて 02:04:46 (7486sec) と表示されていました。

http://img689.imageshack.us/img689/6083/testaviss.jpg v2.54h/u9
http://img138.imageshack.us/img138/9272/testavissu10.jpg v2.54h/u10

http://img205.imageshack.us/img205/1160/scrtst.jpg v2.54h/u9 InfoTip

また、SMPlayer にて再生して確認したところ 03:57:06 と表示されました。

以上のことについて報告しにきたところ、更新版がアップされていたので、v2.54h/u9からv2.54h/u10へとアップデートし、PCを再起動させましたが、上記の状態に変化はみられませんでした。2009/12/8(火) 22:55時点

関連する情報はないかと探したところ、

> Unicode版に、WAVEとAVIのタグが正常に書き込めないバグが見つかりました。

とのことですので、既知の不具合のようですね。実例報告として何かの役に立てばさいわいです。ひとまず報告にて失礼します。

> > Unicode版に、WAVEとAVIのタグが正常に書き込めないバグが見つかりました。
>
> とのことですので、既知の不具合のようですね。

ここで言うタグとはユーザーが入力可能な付加情報のことであって、再生時間などは含みません。ということで、既知のものとは異なります。

可能でしたら以下の点について情報をいただけないでしょうか。
・ANSI版でも現象が再現するか
・XviD以外のコーデックでも再現するか
・ファイル形式がAVI1.0でも再現するか
・同じ形式でファイルサイズがもっと小さい場合でも再現するか

> > Cakewalk SONAR 8.5.1でエクスポートしたwavファイル(44.1kHz 16bit Stereo)のプロパティを開こうとすると、エクスプローラを巻き込んで落ちるようです。
> ご報告ありがとうございます。
> よろしければ現象の発生するwavファイルをいただけないでしょうか。
> 今回の現象は2.54h/u8で初めて発生した現象でしょうか。

返答が遅くなって申し訳ありません。

> よろしければ現象の発生するwavファイルをいただけないでしょうか。
ファイルですが、自分の管理下にあるものではないためそのものをアップすることが出来ません。
申し訳ありません。

> 今回の現象は2.54h/u8で初めて発生した現象でしょうか。
正確には覚えておりませんが、2.54h/u8以前のバージョンでも発生していました。
(何度かインストールして、エラーが出るのでアンインストールしていた記憶があります。)
なお、2.54h/u10に更新後も発生しました。


「Cakewalk SONAR 8.5.1でエクスポートしたwavファイル(44.1kHz 16bit Stereo)」と報告したのですが、
多少検証してみたところ、必ずしも同ソフトでエクスポートしたwavファイル全てがクラッシュの原因になるわけではないようです。

落ちたファイル
・WindowsXP SP3 / Cakewalk SONAR 8.3.1 x86 / 44.1kHz 16bit Stereo
・Windows 7 x64 / Cakewalk SONAR 8.3.1 x86 (WoW64) / 44.1kHz 16bit Stereo
・Windows 7 x64 / Cakewalk SONAR 8.5.1 x64 / 44.1kHz 16bit Stereo
・OS不明 / Digidesign ProTools LE7 / 44.1kHz 16bit Stereo

落ちなかったファイル
・WindowsXP SP3 / Cakewalk SONAR 8.3.1 x86 / 44.1kHz 16bit Stereo
・Windows 7 x64 / Cakewalk SONAR 8.3.1 x86 (WoW64) / 44.1kHz 16bit Stereo
・Windows 7 x64 / Cakewalk SONAR 8.5.1 x64 / 44.1kHz 16bit Stereo
・Windows 7 x64 / Steinberg WaveLab 6 / 44.1kHz 16bit Stereo

上記の通り、フォーマット・ソフトが同じでも落ちたり落ちなかったりと曖昧です。
また、落ちたファイルをバイナリエディタで開いて、RIFFヘッダ/WAVEヘッダとfmtチャンク/dataチャンク以外を削除してみたところ落ちなくなりました。


上記の落ちるファイルはアップ出来ないため、改めて検証用に落ちるファイルを作成してみたいと思います。
ファイルが出来ましたら改めてレスさせて頂きます。

> > 今回の現象は2.54h/u8で初めて発生した現象でしょうか。
> 正確には覚えておりませんが、2.54h/u8以前のバージョンでも発生していました。

もし可能でしたら、ANSI版でも発生するか試していただけるとありがたいです。


> 上記の落ちるファイルはアップ出来ないため、改めて検証用に落ちるファイルを作成してみたいと思います。
> ファイルが出来ましたら改めてレスさせて頂きます。

了解しました。ご連絡お待ちしております。

> Unicode版に、WAVEとAVIのタグが正常に書き込めないバグが見つかりました。
これはAnsi版には影響ないようですね。

> ついでに、WAVEにトラック番号を保存できるようにしてみました。
とりあえずPage_wave.cppも追随します

> これはAnsi版には影響ないようですね。
はい。間違ってUnicode文字列をタグに書き込んでいました。

T-Matsuoさんの書き込みが久しぶりにあり、安堵しています。

mp3infpの今後を教えていただけないでしょうか。
###一応最新版は2.55beta1なのでそれを超えない最大数をバージョンにしているのですが…

2.54aの後継版として2.55を準備中です。
進展があればまたお知らせします。
よろしくお願いします。

http://www.mediafire.com/file/zkm5u2g0imm/mp3infp254i.7z

2.54i alpha1(091223)
1.インストーラの実行権限を明記
2.LAMEでエンコードした22.05kHz VBRのmp3がCBRとして認識されていたのを修正
3.タグを新規作成したときに、タイトルに拡張子が入らないように修正
4.GetFileSize64()、SetFilePointer64()をGlobalCommand.cpp/.hに集約
5.WAVファイルの2GB超過の判定が間違っていたのを修正
6.非対応のID3v2.2フレームがあると、それ以降のフレームが読み込まれないのを修正
7.ID3v2.2とID3v2.3のフレームID変換処理を変更
8.WAVEにトラック番号を保存できるように変更(GUIなし、識別子はITRK)

ID3v2とm3u8関係は手を付けておりません(ソースを直接取りこめるならすぐできたのですが…)。
まったくテストしていません。ただコンパイルが通っただけです。人柱希望者以外は導入しないでください。

来週から外出しますのでこのような形となったことお詫びします。2月中には正式にします。

> 2.54aの後継版として2.55を準備中です。
今のパッチはどうなるんだろうと思うと結構心配です

　どうも、こんばんは。
　不具合らしきものを発見したので、報告致します。
　思うように時間が取れないので検証っぽいことはやれていませんので、本当に報告のみですが……。

(1) InfoTip にファイル名＋拡張子を表示した際に、拡張子が表示されない。
　　(Ex1)「xxxxxxxxxx.wma」の場合、ファイル名部分である「xxxxxxxxxx」しか表示されません。
　　(Ex2)「xxxxxx(09.12.24).wma」のようにピリオド混じりのファイル名の場合、「xxxxxx(09.12.24).24)」のようにおかしな表示の仕方をします。
　　　　（※拡張子（ピリオド含む）を除いたファイル名の右端からピリオドを検索し、該当した箇所から以降の文字列を拾ってる感じでしょうか？）

　　ちなみに、ファイルプロパティ内の「mp3infp」タグ内のファイル名表示部分でも拡張子は表示されませんが、(Ex2) の場合でも拡張子を除いたファイル名のみが表示されています。

なお、InfoTip の設定は「ファイル名: \t\FILE\FEXT\n (以下略)」という感じです。

(2) SUPER © ( http://www.erightsoft.com/Superdc.html ) というソフトを使って動画ファイルを変換した際に、mp3infp の InfoTip では音声ファイルの bps が 0 kbps と表示されてしまう。
　　（mp3 や AAC にて確認。なお、該当ファイルを真空波動研で表示すると、変換時に設定した bps が正常に表示されました。）


◆環境
　OS：Windows XP SP3 (SP3 以降の重要なパッチはすべて適用済み)
　mp3infp Ver.2.54h/u10



＃最近、また mp3 の ToolTip に mp3infp が使用されなくなりました。
＃WMP のパッチが充てられる度に現象が出るのかなぁ……？

> (1) InfoTip にファイル名＋拡張子を表示した際に、拡張子が表示されない。
> 　　(Ex1)「xxxxxxxxxx.wma」の場合、ファイル名部分である「xxxxxxxxxx」しか表示されません。
> 　　(Ex2)「xxxxxx(09.12.24).wma」のようにピリオド混じりのファイル名の場合、「xxxxxx(09.12.24).24)」のようにおかしな表示の仕方をします。
> 　　　　（※拡張子（ピリオド含む）を除いたファイル名の右端からピリオドを検索し、該当した箇所から以降の文字列を拾ってる感じでしょうか？）
不具合が見つかりました。致命的と言うほどではないですが、おそらく2.xx全バージョンに存在します。
GlobalCommand.cpp:270
- CString fName = getFileName(path);
+ CString fName = getFileNameExtName(path);
原因はこちらを参照: http://win32lab.com/bbs2/index.cgi?no=10162&reno=10159&oya=10120&mode=msgview
#同じ関数名を複数宣言できるC++の恐ろしさがここにある。

速いうちに2.54i beta1を出したいと思います(beta1は、ID3以外は安定版扱いとするので、出した時点で2.54hは削除します。欲しい方はお早めに)。
#m3u8は普通にANSIに変換して設定でいいですよね?こちらは最低限の機能で。

> 　　ちなみに、ファイルプロパティ内の「mp3infp」タグ内のファイル名表示部分でも拡張子は表示されませんが、(Ex2) の場合でも拡張子を除いたファイル名のみが表示されています。
こちらは仕様と思います。

> (2) SUPER © ( http://www.erightsoft.com/Superdc.html ) というソフトを使って動画ファイルを変換した際に、mp3infp の InfoTip では音声ファイルの bps が 0 kbps と表示されてしまう。
> 　　（mp3 や AAC にて確認。なお、該当ファイルを真空波動研で表示すると、変換時に設定した bps が正常に表示されました。）
こちらは高田氏にお願いしときますか--;