[1-] [101-] [201-] [301-] [401-] [501-] [601-] [701-] [801-] [901-] [1001-] [最新50] [検索] ※標準/名無しさん
※このスレッドは終了しています
1 旧黒の部屋EX(1063)
1 管理者 : 2004-07-13 01:14:52 [zXIVQd5A]- 旧黒の部屋EX(生産物掲示板)の中身です。
参照にどうぞ。
書き込みは不可にしてありますので、
それぞれ真空か、その他の方のスレッドで続きお願いします。 821 黒羽◆bdHRRNwznCvbs : 2003-12-26 15:26:57 [rpXqCKEs]- 031207a
http://jan.sakura.ne.jp/~haireria/kurohane/lzh /sinkuhadouken_031207a.zip
HISTORY.TXTに書きましたが、MP3系全てほぼ1から書き直してます。
全て自力取得、MP3系はmp3infpを使わなくなりました。
LAMEタグの方はまだまだ出せますが、出して面白そうなのがあんまり無いのでこれくらいにしときます。
で、再生時間とVBRビットレートの計算ですが、
決まった方法というのが1種類ではなく(mp3infpとは違う方法使ってます)、
ビットレートがmp3infpと食い違うmp3がいつくかあります。
私が取った方法はあくまでもXingタグを信用する方法なので、
Xingタグに矛盾があるMP3(ファイルを後半ぶった切ったとか)は、結果が恐らく狂います。
全フレームスキャンする必要も無いので速度的にも有利ですが、
ブツ切ってる場合、
mp3infpが取ってるような自力で総フレーム数を調べて計算する方が
「その状態でのMP3」としては信頼できる値を出します。
現状は、
フレーム数 -> Xingタグから
ファイルサイズ -> 実ファイルから
になってます。
ファイルサイズ(というよりMP3のデータとしてのサイズ) を、
Xingタグから取ると、今度はブツ切ってても切る前でのレート計算になります。
ここらへんはどうするかまだ考えてますが、
とりあえずテストって事で色々試してもらえれば助かります。
今で、大体getid3と同じような計算結果になります。
大体というのは処理系依存で小数点の丸め込みが違う為です。
...一応doubleの精度でやっているにはやってるんですが;-;
＞山本 和宏さん
すみません、旧バージョンもう手元にありません。
使っていたバージョン教えてもらえれば、掲載紙の付録CDから探してみます;-;
[ALL] [LAST100] [1-100] |