[戻る]

[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]

megabbsっぽい PHP+MySQL +NGワード +DNSBL 111102 / 黒羽製作所