LAMEコマンドラインオプションを語れ！その22

LAMEコマンドラインオ ..

39:名無しさん＠お腹いっぱい。
06/12/31 17:48:15 hFte18tr0
今まで音が凄く割れた曲があって、
試しにmp3の192Kbpsにしたら全然しなくなった…。
ちなみにﾛｽﾚｽとかAAC192kbps、WAVしてみたけど、音割れはする。

40:名無しさん＠お腹いっぱい。
06/12/31 17:56:56 UjVDSo270
よいお年を。

41:名無しさん＠お腹いっぱい。
06/12/31 20:13:11 wmp7wWOi0
>>39
ためしに -k を付けてエンコしてみるとどうですかね。
問題は高周波数の再生がつらい機器の方にあるような気がする。

42:名無しさん＠お腹いっぱい。
07/01/01 00:04:53 1FC3a8Ir0
あけおめ。今年のLAMEはまずは3.98 stableだな。

43:名無しさん＠お腹いっぱい。
07/01/01 00:10:00 McSpWRfl0
あけましてらめぇ

44:名無しさん＠お腹いっぱい。
07/01/01 00:34:38 xNGiQIFO0
ぁめｳﾏｰ

45:名無しさん＠お腹いっぱい。
07/01/01 00:35:06 js7RP1u80
明けましてらめぇ
今年も一年らめぇ

46:名無しさん＠お腹いっぱい。
07/01/01 00:42:21 XVAZ2ZBW0
3.99ではLAME Lossless CodecというMP3との差分可逆フォーマットが追加されて
WavPackみたいに使えるらしいぞ。

47:名無しさん＠お腹いっぱい。
07/01/01 00:50:11 OlYcs9Yg0
今日は4/1じゃないですよ

48: 【大凶】【1604円】
07/01/01 01:53:05 LluvL0HB0
あけらめぇ

49:名無しさん＠お腹いっぱい。
07/01/01 02:29:23 L8la6vDp0
お面

50: 【豚】【1468円】
07/01/01 02:54:21 L8la6vDp0
3.98にケリがつきます様に

51: 【凶】【1904円】
07/01/01 07:12:14 MnjfsbgD0
らめ

52:名無しさん＠お腹いっぱい。
07/01/01 12:23:41 tsyCkjxD0
らめぇぇぇぇぇぇぇ！

53:名無しさん＠お腹いっぱい。
07/01/01 21:40:39 i0qmOAnj0
真のLAME信者は毎日３食をラーメンで凌ぎます。

54:名無しさん＠お腹いっぱい。
07/01/02 02:33:11 Qgkt+B9e0
3.99の次は4.0がリリースされると思ったら大間違いだからね
その次は3.100だから

55:名無しさん＠お腹いっぱい。
07/01/02 02:41:30 IweUrvso0
3.99の次は3.991で3.999の次は3.9991なので4.0に無限に近付きますが到達はしないでしょう。

56:名無しさん＠お腹いっぱい。
07/01/02 03:10:59 f7sylggG0
reaperかよｗ

57:名無しさん＠お腹いっぱい。
07/01/02 03:19:09 mgu4s9XWP
まあ、4.0はすでにアルファ版が出てる以上、
3.9系が4.0に上がるのはマズいだろうな。

58:名無しさん＠お腹いっぱい。
07/01/02 03:37:32 1u9ioZK+0
どの段階でCVS HEADを3.xから4.0にするかだな
今の開発ペースでは当分なりそうにないがw

4.0のゴールはtt氏が比較的明確に出してるんだけど、3.9xのロードマップってどうなってるんだろうね

59:名無しさん＠お腹いっぱい。
07/01/02 04:04:05 tTth14gE0
これからV2でエンコする場合、どのver.使いますか？

60:名無しさん＠お腹いっぱい。
07/01/02 05:07:55 ZRtB21N80
統合したら7でいいよ。どうでもいいけど
それより3.98 stable

61:名無しさん＠お腹いっぱい。
07/01/02 05:32:15 Ur0rL7GY0
>>57
Lame4って一人のジャッププログラマーのオナニーじゃなかったの？
ジャップの作ったのは非公式にして改めて4を作ればいいじゃん

62:名無しさん＠お腹いっぱい。
07/01/02 10:40:10 mKkUL8bm0
WinnyでMP3ファイルを手に入れたのだが、10曲が1つのMP3ファイルになっている、
これを1曲ずつ10個のMP3ファイルに分けたいのだがどうしたらいいのかね？

63:名無しさん＠お腹いっぱい。
07/01/02 10:42:11 mqGozhlQ0
>>62
お前このスレもみてんのかよ

64:名無しさん＠お腹いっぱい。
07/01/02 10:48:43 lK+C+sSH0
>>63
>>62は上位スレ爆撃してるみたいだね、この池沼は

65:名無しさん＠お腹いっぱい。
07/01/02 11:06:13 h9fsbbab0
このスレで.zip.mp3ネタで釣りをする香具師が居るとは思わなかった。

66:名無しさん＠お腹いっぱい。
07/01/02 15:00:58 IvMNbk/s0
3.97を色んな所から落としたんだけど解答したらファイルサイズが違う、コレは別に気にしなくていいの？

67:名無しさん＠お腹いっぱい。
07/01/02 15:23:47 1u9ioZK+0
だからコンパイラとそのコンパイルオプション次第でいくらでも変わるとあれほど
公式にはソースコードしか提供されていない

68:名無しさん＠お腹いっぱい。
07/01/02 15:44:13 aJzn5idU0
違うサイズのやつ実行するとPCが爆発四散するよ

69:名無しさん＠お腹いっぱい。
07/01/02 16:02:50 Rq6sEbr00
>>66
ウイルス入りのLAMEを配布している所もあるらしいよ…

70:名無しさん＠お腹いっぱい。
07/01/02 17:08:28 P0z3Abud0
チンコ入りのlameを配布している所もあるらしいよ…

71:名無しさん＠お腹いっぱい。
07/01/02 17:17:02 mqhzreHG0
お年玉付きだよ

72:名無しさん＠お腹いっぱい。
07/01/02 19:15:46 +JuEGZGM0
誰もがそれぞれに違った形のLAMEを胸の奥に持ってるらしいよ

73:名無しさん＠お腹いっぱい。
07/01/02 23:47:49 kjnbKtXh0
つまり、LAMEとは人々の夢という意味だったのですね！！

74:名無しさん＠お腹いっぱい。
07/01/02 23:50:25 htQeK1w40
そして人々の希望

75:名無しさん＠お腹いっぱい。
07/01/03 00:47:25 7m3smBdL0
もうlameスタッフで新しい音声規格作っちゃえばよくね？

76:名無しさん＠お腹いっぱい。
07/01/03 10:55:40 nZ6v5yO+0
っていうか、らめぇって何でフランス語読みするの?
LAME Ain't Mp3 Encoderの省略なら英語読みで「れぃむ☆」が妥当じゃない?

77:名無しさん＠お腹いっぱい。
07/01/03 10:58:18 aMBk7U2C0
普通にローマ字読みだと思うがｗ

78:名無しさん＠お腹いっぱい。
07/01/03 11:29:31 C2I4USak0
フランス語で発音しちゃらめぇ

79:名無しさん＠お腹いっぱい。
07/01/03 22:29:15 4I/gFUQE0
>>76
僕のれぃむぽを触っちゃらめぇぇぇぇぇぇっ！！！

80:名無しさん＠お腹いっぱい。
07/01/04 00:10:50 BRHLk9WI0
で、お前らどのLAME使ってんの？

81:名無しさん＠お腹いっぱい。
07/01/04 00:14:51 dl9T1d1D0
>>22
This Account Has Been Suspended
Please contact the billing/support department as soon as possible.

ｵﾜﾃﾙ＼(＾o＾)／

82:名無しさん＠お腹いっぱい。
07/01/04 00:22:55 vOtr9fzy0
>>81
URLﾘﾝｸ(lame.bakerweb.biz)

83:名無しさん＠お腹いっぱい。
07/01/04 13:00:55 1IYkiBEs0
で、結局一番いいオプションは何？

84:名無しさん＠お腹いっぱい。
07/01/04 13:30:11 G3DCwj8/0
らめぇぇぇっぇぇぇぇぇぇぇっぇぇぇぇぇっっっぇぇ！！！！！

85:名無しさん＠お腹いっぱい。
07/01/04 14:56:04 kNa0snBV0
-らめぇ

86:名無しさん＠お腹いっぱい。
07/01/04 15:06:43 74WoYchH0
>>81

もう既に　>>30

87:名無しさん＠お腹いっぱい。
07/01/04 15:09:22 74WoYchH0
>>82
年明け早々にて更新しているのか。
なんともはや。

88:名無しさん＠お腹いっぱい。
07/01/04 20:54:49 31Se/M5D0
rarewaresの復活の予定はいつなの？ていうか復活するの？

89:名無しさん＠お腹いっぱい。
07/01/04 21:09:00 H22stSvE0
>>88
サーバを借りてた人(rarewaresの管理者とは別)が、より料金の高いプラン(VPS)で借り直すらしい
それまでしばし待て

その人に申し訳ないので寄付を受け付けようかという話になっとるね

90:名無しさん＠お腹いっぱい。
07/01/05 05:49:30 lS2591Sm0
torrent使えよ

91:名無しさん＠お腹いっぱい。
07/01/05 09:32:52 RRL4DlOT0
rarewares.orgに置いてあったLAMEはrarewares.orgの管理人さんがビルドしたものだったのかな？

92:名無しさん＠お腹いっぱい。
07/01/05 12:21:18 z2MjQ5B/0
　ｧ　　　 _, ,_　ｧ,､
　,､'` （　｀∀´）　,､'`
　 '` 　( ⊃⊂)　　'`

93:名無しさん＠お腹いっぱい。
07/01/05 21:35:18 kvo2zHoQ0
鯖落ちなんて、そんなの○○ぇぇぇぇっ！！！

94:名無しさん＠お腹いっぱい。
07/01/06 17:08:44 8svoq+JU0
らめ。らめえぇぇ！

95:名無しさん＠お腹いっぱい。
07/01/06 22:01:17 TLj/I/+90
2004年 7月 29日木曜日、11:19:52更新のlameをつかって
--preset standard
でエンコしています。
新しいバージョンにかえたほうがいいでしょうか。
その場合、同等のコマンドは
--preset fast standard
になるのでしょうか。

96:名無しさん＠お腹いっぱい。
07/01/06 22:03:41 mGhQRDha0
>>95
バージョンがわからないと何も言えない

97:名無しさん＠お腹いっぱい。
07/01/06 22:03:42 GsDLSw2b0
そんなLameらめぇ

98:95
07/01/06 22:21:02 TLj/I/+90
>96
バージョンの調べかたがわかりません。

99:名無しさん＠お腹いっぱい。
07/01/06 22:22:55 KxaD+/1o0
>>95
オフィシャルサイトの更新履歴からバージョンを推測すると3.96.1かな？
それはともかく新しいバージョンに変えた方が良いと思う。
最新ステーブル版の3.97か最新版の3.98a11が良いかと。
コマンドラインは3.97ならそのまま、3.98a11ならどちらでも良い。
URLﾘﾝｸ(lame.bakerweb.biz) （3.98a11がDL出来る）
URLﾘﾝｸ(www.free-codecs.com) （3.97、3.98a11がDL出来る）

100:名無しさん＠お腹いっぱい。
07/01/06 22:34:49 t1fBteYc0
優しさに涙らめえぇぇぇ!

101:名無しさん＠お腹いっぱい。
07/01/06 23:10:33 oPmKI2y/0
俺、rarewaresが落ちる前にa11落としたんだけど、
もしかしてウイルスが入ってたりする？チェックしても出なかったけど・・・

もし入ってたら・・・らめぇぇ！！！

102:95
07/01/06 23:17:25 TLj/I/+90
>99
ありがとうございます。
昔はこのスレに入り浸っていたんですが、ちょっと離れると何もわからなくなってしまって。
あのころに比べるとHDDの値段がかなり安くなっているのでやる気が出ます。

103:名無しさん＠お腹いっぱい。
07/01/06 23:44:21 RNF/Vkgg0
むしろHDDが安くなったなら可逆で（ｒｙ

104:名無しさん＠お腹いっぱい。
07/01/07 00:03:37 jmcdUL7A0
可逆には夢がない。
不可逆だからこそ技術の進歩を確認できるし、未来に希望を持てる。

それくらいに、らめぇぇぇを愛することって、そんなに不思議な事じゃない。

105:名無しさん＠お腹いっぱい。
07/01/07 00:10:55 eoy5WtI40
>>104
無圧縮でも如何にして原音に忠実に標本化するかで技術の進歩が確認できるし
可逆でも如何にして圧縮効率を上げるかによって技術の進歩が確認できる

106:名無しさん＠お腹いっぱい。
07/01/07 00:13:05 OR7xQfeY0
可逆で実用性無視したらどれくらい縮むのかは興味ある

107:名無しさん＠お腹いっぱい。
07/01/07 00:19:49 eoy5WtI40
そういや前に音を量子化じゃなくて全てサインとかの関数で表現したら圧縮率がかなり高くなるって話を聞いたけどどうなんだろ？

108:名無しさん＠お腹いっぱい。
07/01/07 00:22:20 1Rpg7nCH0
multi-passかなんかでソース毎に最適な予測器のアルゴリズムを選んだりするのかな
MPEG-4 ALSに使われてるPARCOR係数は人の声の予測用だったか

109:名無しさん＠お腹いっぱい。
07/01/07 00:23:04 1Rpg7nCH0
>>107
それvaporwareでしょ...

110:102
07/01/07 00:32:26 1JUCYY1X0
>103-109
議論されていることはまったく変わっていない。。。。

111:名無しさん＠お腹いっぱい。
07/01/07 00:35:43 njw3Fi5N0
歴史は繰り返す

112:名無しさん＠お腹いっぱい。
07/01/07 02:20:11 x02oTJ8P0
らめぇも繰り返す

113:名無しさん＠お腹いっぱい。
07/01/07 03:08:38 sOdMPsHJ0
出ないなら　出るまで待とう　3.98安定版

114:名無しさん＠お腹いっぱい。
07/01/07 03:18:48 1t2/daO80
出ないなら　出してしまおう　4.0

115:名無しさん＠お腹いっぱい。
07/01/07 04:52:44 WxCb2WrP0
やっぱり不可逆は技術的に面白くてロマンがあるよねー。

>>107
フーリエ変換だね。
すべての音はサイン波の組み合わせであるという。
DTMでそういうソフトがあったような・・・。

116:名無しさん＠お腹いっぱい。
07/01/07 04:53:07 I4b+4p4X0
preset fast standard
preset fast medium

117:名無しさん＠お腹いっぱい。
07/01/07 05:48:49 NQa8ieBa0
>>107
URLﾘﾝｸ(www.jgs-g.co.jp)
もうリンク先はなくなってる。

118:名無しさん＠お腹いっぱい。
07/01/07 08:59:30 G4nr7R/I0
ｽﾚﾘﾝｸ(kankon板)

119:名無しさん＠お腹いっぱい。
07/01/07 13:35:12 jlzKKfs00
>>106
MD5ハッシュ128ビットのみHDD保存。
再生時にP2Pネットワークからストリーミング再生ｗ
上りが100mbps超えたら可能かもな。
リアルタイムじゃないけど、それってWinnyじゃんｗ

120:名無しさん＠お腹いっぱい。
07/01/07 14:53:33 FGOzBous0
>>119
何かをどうかすれば LAN で実現できそうな物だな。
Client <=> Server <=> Backend DB (NAS)
　　　　MD5　　　　 Query

121:名無しさん＠お腹いっぱい。
07/01/07 15:17:44 nPucj1H+0
>>119
それ可逆圧縮？

122:名無しさん＠お腹いっぱい。
07/01/08 06:41:17 DXYM5Osg0
辞書圧縮も可逆圧縮に入れていいんじゃないの?
辞書が空なのと何か入ってるのの区別で最短は2ビットかな?

123:名無しさん＠お腹いっぱい。
07/01/08 14:13:31 jLcffUQ+0
URLﾘﾝｸ(www.rarewares.org)
復活らめぇ！

124:名無しさん＠お腹いっぱい。
07/01/08 14:28:36 bez4h6Qt0
らめぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇ！！！！！！！！！！！

125:名無しさん＠お腹いっぱい。
07/01/08 14:53:15 OW5o/sWD0
復活おめでとうらめぇぇぇぇぇぇぇぇ

126:名無しさん＠お腹いっぱい。
07/01/08 15:54:18 Z68VuyWO0
LAME 3.98 alpha 11

らめぇええええええええええええええええええ

127:名無しさん＠お腹いっぱい。
07/01/08 16:04:55 nTOkVYEL0
それより何より、3.98 stable早くらめぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇ

待ちきれずに3.97 stableでエンコしちゃったらめぇ

128:名無しさん＠お腹いっぱい。
07/01/08 17:47:24 LuxiyRVZ0
3.98の何がどうなったらstableなんだろね・・・。
a版のまま更新が続くってことはバグがまだあるってことなのか、
それともバグは無いが開発者の納得いかない部分がまだあるのか。。。

129:名無しさん＠お腹いっぱい。
07/01/08 18:08:21 hDDuNqOn0
qが未完成、4.0のコードをどこまでマージするか等いろいろと・・本家に行け

130:名無しさん＠お腹いっぱい。
07/01/08 23:24:07 j9+WS2VD0
インテンシティステレオ実装まだなのからめぇ

131:名無しさん＠お腹いっぱい。
07/01/09 00:38:42 m5j8BwyqP
rarewares にある ICL でコンパイルされたバイナリ
MSVC8 で自分でコンパイルしたバイナリ(*1)
cygwin で自分でコンパイルしたバイナリ(*2)

で同じwavファイルを同じオプションでエンコードしてもmd5sumが一致しない。
rarewares のバイナリはエンコード時間が一番早い。(Core 2 Duo E6300 @定格
で6:36秒の曲が28秒、*1だと53秒。*2だと35秒。)

MSVC8 の浮動小数点の精度はデフォルトが/fp:presizeなので(ICLのデフォルトは
処理速度優先。gcc(=cygwin) でのデフォルトも -ffast-math で処理速度優先。)
/fp:fastにしたらエンコード時間が30秒になった。

しかし同一音源で全く同じmp3ファイルがはき出されないんだがこれでいいんだろうか。
つうかmp3ファイルが同一でなくてもデコードしたら同一になることってmp3の
仕様上okなんだろか。

132:名無しさん＠お腹いっぱい。
07/01/09 00:41:10 m5j8BwyqP
書き漏れ。

>>131
＞mp3の仕様上okなんだろか。
もしokなら今度はデコード後をコンペアしてみてみるという手が残ってるなあ…

133:名無しさん＠お腹いっぱい。
07/01/09 00:53:49 nt3reyTD0
元のmp3ファイルが微妙に違えばデコード後は一致しないのでは?
少なくとも俺の経験上ではそうだ。

まあ、一致しないとは言ってもほんの僅かの差だから、差を知覚できないとは思うけど。

134:名無しさん＠お腹いっぱい。
07/01/09 04:28:41 ZFK0XaGj0
それは削る部分をコンパイラが計算するときの差で当然そうなるんじゃないかい？
内部精度の違いとか最適化とか誤差とか。

135:名無しさん＠お腹いっぱい。
07/01/09 14:34:17 F75O+nWN0
ところでlame3.98a5使ってるんだが、a11の方が良いか？

136:名無しさん＠お腹いっぱい。
07/01/09 14:41:10 UFccrCtf0
>>135には違いが分からめぇ

137:名無しさん＠お腹いっぱい。
07/01/09 15:34:04 inU3tqHu0
おい
お勧めver教えてください

138:名無しさん＠お腹いっぱい。
07/01/09 15:50:54 tik2giXy0
>>137
>>99

139:名無しさん＠お腹いっぱい。
07/01/09 21:22:15 m5j8BwyqP
>>134
まさにその通りだと思います。最適化で計算結果が違ってしまうのが
デフォルト(ICL, gcc)というのはなんだかおかしいような気が。
どちらも浮動小数点演算の精度を最適化の影響なしにするオプションが
ちゃんとあるのに。(というか gcc はデフォルトがMSVC8と同様、精度重視。)

このあたり開発者さんたちは気にしてないんだろうか。

140:名無しさん＠お腹いっぱい。
07/01/09 21:49:11 Hr9eXWJJ0
　　　　　　　　　　　　　　　　　　　　　　　　　　　ヽ
　　　　　　　　　　　　　　_,,.,､､,.ｨ-- ti- ､､､....,,,,_ 　 ',
　　　　　　　 ,,..､､ri':'ﾞ/~ 　ﾚ　　　 '　ﾞﾍ:l : : : :~,＞
　　 _,...r:::''"::／ l/ .l:/-=ニ二,'_ｰ- ､、　 !l!;: r '"
'''＜:::::::::::::;､r'　　　　　　　　　　`'' ‐-`.､ /
-、 l::::::::::::l　　　　　　　　＜"ﾞ'i;ｿ'　　 ',
~.ヽ l:::::::::::l　　　　　　　　　　　　 ~' 　　 '､
/ .） .l::::::::::!　　　　　　　　　　　　　　　 '､
　ヽ　.l:!l:::::l ヽ　　　　　　　　　　　　　　　　 '､
＼ '　 l! l::!l!　ヽ　　　　　　　　　　　　　　 ,'
　ﾞ　　ヾ　　　　　　　　　　　　　　　‐'" ,. r ﾞ
ｰ-‐i　　　　　　　　　　　　　 ,.r,,iilll鬚髯ｦ　　　そんなに何も見えてないんじゃ
.　　 l　　　　　　　　　　　　`''' ‐‐ ---t‐' 　　　　
￣￣￣￣￣￣~"''､' ‐ ､　　　ー‐ノ　　　　　生きてても面白くないでしょう
　　　　　　　　　　 ',　ヽ　　　　　 l
　　　　　　　　　ｌ　　 l　　　　 l
　　　　　　　　　　 l　　 l　　　　ﾉ

141:名無しさん＠お腹いっぱい。
07/01/10 00:37:55 wL8Zm1Xb0
コンパイラによって処理を意図的に変えてたりしてなｗ

142:名無しさん＠お腹いっぱい。
07/01/10 01:46:07 BSFjFCaD0
吉井さん！

143:名無しさん＠お腹いっぱい。
07/01/10 02:10:40 r4aTlhRQ0
>>139
出力される結果(バイナリ)が違うのは確かに困るかもしれないけど
開発者としてはデフォルトで一番高速っていうほうが気持ちいいんじゃない?
個人でICLとgccの両方使うような奇特な人はオプションつけてコンパイルするだけの
スキル・知識があるだろうしねぇ。

ICL,gccをABXテストで聞き分けられるというレベルだったら話は違ってくるんだろうけど、
だれかやってみる?

144:名無しさん＠お腹いっぱい。
07/01/10 02:31:56 aea9TKWk0
つーか何で今更そんな話が話題になるの

145:名無しさん＠お腹いっぱい。
07/01/10 04:08:18 r4aTlhRQ0
基本的にはエンコーダはデコードできる物ならなんでも出力していい。
デコード結果が違っても別に仕様なんだからいいんじゃない?
LAMEとiTunesのエンコーダでも結果違うでしょ?

146:名無しさん＠お腹いっぱい。
07/01/10 04:50:06 kHOJ3maIP
バイナリの違いによる出力MP3ファイルの違いが有為な(聴き取り可能な)差
だという前提で考えると…

だめだと思います。仮に許容するとしても、音質比較の際には
どのバイナリでエンコードしたものなのかを示す必要がでてくると思います。
(もちろんiTunesの場合でもバージョンを明示する必要はありますが。)
推奨オプションなどにもバイナリを明記する必要が出てくるかも。

有為な差ではないならこれらは誤差としてしまうことも可能でしょうが。

割と簡単な解決だと私が思うのは、『浮動小数点の精度を落とさないように
してコンパイルする』というものです。

正しい解決は『どのコンパイラにかけてもどんな最適化をされても
同じ出力が生成されるソースを書くこと』です。

147:名無しさん＠お腹いっぱい。
07/01/10 04:51:44 kHOJ3maIP
それから

>>145
＞デコード結果が違っても別に仕様なんだからいいんじゃない?
デコード結果が違ってるかどうかはまだ検証していません。

148:名無しさん＠お腹いっぱい。
07/01/10 05:03:45 Db9iDRS20
ogg vorbis高速化では
URLﾘﾝｸ(homepage3.nifty.com)
FPU→SSEにしてることで、内部精度80bit→32bitに落ち、当然エンコード結果はリファレンスと異なる。
コンパイラで最適化オプションをつけたときもリファレンスのバイナリと結果が変わってしまって
いるのだけど、それぞれを聞き分けられた、という話はいまだ聞かない。

149:名無しさん＠お腹いっぱい。
07/01/10 05:10:42 r4aTlhRQ0
いや、エンコーダのバイナリ違うんなら明示するのが普通だろ。
ソース公開されてるんだし自分でいじることも可。
コンパイラの違いによってエンコード結果が違って困ることより
嬉しいことのほうが多いから、その簡単な解決方法は
あなたが自分でコンパイルするときに実行してください。

他人から渡されたバイナリが自分のとこでエンコードしたものと違うと
非常に困るというシチュエーションがあったら教えてもらえますか?

150:名無しさん＠お腹いっぱい。
07/01/10 05:13:53 r4aTlhRQ0
>>147
デコーダの出力も本当に世界中で流通しているものがすべて同じ結果をだすのか
調べてからいってますか?
mpg123とMADでもわずかですが違います。
デコーダによって結果が違うような物をエンコードするのに結果の一致などという
不毛なことに時間を費やすのは無駄です。
可逆圧縮ではないのですよ?

151:名無しさん＠お腹いっぱい。
07/01/10 07:43:32 kHOJ3maIP
なぜいきりたってるのかよくわかりませんが。

>>149
＞コンパイラの違いによってエンコード結果が違って困ることより
＞嬉しいことのほうが多いから...
具体的にどんなときですか？

＞他人から渡されたバイナリが自分のとこでエンコードしたものと違うと
＞非常に困るというシチュエーションがあったら教えてもらえますか?
そうですねぇ。まず公式と称されているバイナリが信用できなくなります。
かつ、どのバイナリで評価したのか不明な評価が一人歩きしたりして
いろいろな情報があてにできなくなります。

ところでバイナリによってエンコード結果が違うことがなぜ
あなたにはそれほどまでに困ることなんですか？

152:名無しさん＠お腹いっぱい。
07/01/10 07:45:59 kHOJ3maIP
>>150
＞デコーダの出力も本当に世界中で流通しているものがすべて同じ結果をだすのか
＞調べてからいってますか?
アホかいな。何度も「まだ検証していない。」って書いてるじゃん。

＞デコーダによって結果が違うような物をエンコードするのに結果の一致などという
＞不毛なことに時間を費やすのは無駄です。
いいえ、不毛ではありません。デコーダ間で結果が違うのは
デコーダがMP3の仕様を満たしてないとかが原因かもしれません。

＞可逆圧縮ではないのですよ?
だから？

153:名無しさん＠お腹いっぱい。
07/01/10 07:56:09 6v+J8T9c0
王子の書き込みが無いと生きていけない

154:名無しさん＠お腹いっぱい。
07/01/10 08:03:42 kHOJ3maIP
それから浮動小数点演算の精度の違いで生ずるエンコード結果の違いが
有為でないことを証明・保証しておかないと知らない間に有為な差が
生じてしまう可能性もありますね。
（つうか私が知らないだけですでにどこかで証明・保証されてるのかも。）

EACのオフセットみたいに「だれも気がつかなかったからいいじゃん。」でok
というのも一つの見識だとは思いますが。

155:名無しさん＠お腹いっぱい。
07/01/10 08:35:46 2tMO4Ko/0
>>151

Lameに公式とされてるバイナリなんてあるのか？
公式にはソースしかこうかいされてないはずだが

RareWaresのは１サイトのメンバーがコンパイルしたものだっていうだけだしな。
まぁ有名サイトだから、評価の際にそこのバイナリを使って評価しましょうって
だけで公式ってわけじゃない。

ましてRareWaresのバイナリが、一番正確に演算されてるとは限らないんだよな。

156:名無しさん＠お腹いっぱい。
07/01/10 08:50:54 QDxBC8+J0
ようするにMPEG Audioの仕様の中にエンコード・デコードの演算精度についての
規定があるかってことが知りたいってことでいいか？

157:名無しさん＠お腹いっぱい。
07/01/10 08:53:26 8F/Vrm9w0
熱くなれるのはいいことだ。

158:名無しさん＠お腹いっぱい。
07/01/10 08:58:34 kHOJ3maIP
>>155
>Lameに公式とされてるバイナリなんてあるのか？
ないと思います。おっしゃる通り公式にはソースのみ。

今回の件でいろいろ調べていると、開発者の方が「Officialはアレ」と
言っている記述を何回か見かけたので…（ちょっと文脈が違うかも
しれませんが、開発者の認識としてはそうなんかと。)

>ましてRareWaresのバイナリが、一番正確に演算されてるとは限らないんだよな。
というかどっちかっつうとICL使ったり結構チャレンジャーなバイナリかも知れませんね。

159:名無しさん＠お腹いっぱい。
07/01/10 16:19:26 NUSNyJB/O
無知な俺には、おまいらが同じ世界の人間だとは思えないんだぜ

160:名無しさん＠お腹いっぱい。
07/01/10 18:34:42 Db9iDRS20
URLﾘﾝｸ(www.hydrogenaudio.org)
斜め読みしかしてないから役に立つかはわからないけど、
やはり同じ事が気になっている人はいるようで。

161:名無しさん＠お腹いっぱい。
07/01/10 18:58:31 OXJ1CZ+b0
結論はlameの開発者自身が言ってるようだが。
>You should not worry, as the differences are very small (unless something is broken, but then it's a different matter)

どうしても気になるって人はABXテストで区別できるようなサンプルを持ってくるべきだな。

162:名無しさん＠お腹いっぱい。
07/01/10 19:54:53 r4aTlhRQ0
x86のICLとgccだけくらべても意味なんて無い。
データ型の精度だってアーキテクチャによって違う。
最低限の精度は規定されているが上限に関してはない。
データ型の精度はいまのところほとんどの環境で同じだから大丈夫だが
演算の精度までは規定されていなかったはず。
64bitの浮動小数点の演算を内部で80bitで処理しようが256ビットで処理しようが
かまわない。

163:名無しさん＠お腹いっぱい。
07/01/10 20:20:16 2tMO4Ko/0
けっきょく、演算精度の差が気になるなら、mmx/sse/sse2/3dnow!なんかのオプションを
全てオフにしてコンパイルしろってことかな。

164:名無しさん＠お腹いっぱい。
07/01/10 20:30:08 OXJ1CZ+b0
それ以前にfp演算は計算の順番だけで精度が変わるから。

165:名無しさん＠お腹いっぱい。
07/01/10 20:53:10 r4aTlhRQ0
たとえばgzipだったらエンコード(圧縮()してデコード(展開)した結果がコンパイルオプションに
よって違うというなら大問題だろう。
元が16ビットの整数なのを勝手に中で浮動小数点で計算してるんだよね。
で、計算してこねくりまわした結果をまたビット表現というかたちの整数にまた変換する。
デコーダもまたMADみたく整数で処理したりmpg123みたく浮動小数点で処理したり。
そして出てきた出力もOSでリサンプリングされてミキサーを通してサウンドカードの
イコライザを通してマルチビットDACだったり1ビットDAだったりでアナログにして
スピーカから音を出す。
もう32ビットだろうが64ビットだろうがどうでもいいよ。

16ビットPCMのLSB削られても同じ音量だったら聞き分けできない俺がいってみる。

166:名無しさん＠お腹いっぱい。
07/01/10 21:21:18 r4aTlhRQ0
つか、その16ビットのデータだって元はもっと高精度なデータで
ディザかけて16ビットにしてるんだから……

167:名無しさん＠お腹いっぱい。
07/01/10 21:35:38 +IUPoqw60
それならデジタル信号をそのまま脳みそに垂れ流す機械作れよｗ

168:名無しさん＠お腹いっぱい。
07/01/10 21:59:20 ltNijOsW0
　　█▓▓█▀▓▉　▋　▀▋　▉ ▊ ▋ 　 ▎ ▌▉　 ▋　▀▋ 　　 ▊　▎ ▌ ▊
　 ◥█▓▀▉　▓▊▐▂▄▃▌▄▊ ▋ ▊　 ▍ ▋█▃▲▄▂▲ 　▍　▋　▍　▼
　　█▓　▼ ▓▋▐◣▃▅▆▆◣▃▌ ▊　▌ ▊█▃◢▆▆▅◣▋ 　▌ ▐　 ▌　▲
　　◥▇▓ 　▌ ▀▌▐▀◣ ▀▓▅　▀◣▋ ▋ █◤▀　▀▓▅ ◢▋　▲　▍ ▋　▓▌
　　　█▓　 ▍　▐▀◣ 　 ▀▀　　　 ◥▊▼ 　　　▀▀　 █▃▀▋▐▅▋　▓▌
　　　 █▓◣▲ 　▓▄　　　　　　　　　　　　　　　█▀　▓　▓▋▃▓▌　それはらめ。
　　　　▼▀█▓▅▓▀◣　　　　　　▌　　　　　　◢▀　▅▓▆▓ ▀▓▉
　　　　　　　█▓█▓▆▃　　　　　 ▀　　　　　　　▄▆▓▓█▓ 　▓▉
　　　　　　　█▓▀▆▃▀◣▂ 　　 ▄▂▂▂　　　　◢▀▃▓▓█▀ ▃▓▀
　　　　　　　　▀▓▃▀█▅▃▂　　　　　　　　　▄▆▀　█▀　 ▼
　　　　　　　　　▼▀◣ ▀██▃　　　　　　　　▃▆▀▃▆▀　▅▀

169:名無しさん＠お腹いっぱい。
07/01/10 22:31:14 peW7PDRZ0
　　█▓▓█▀▓▉　▋　▀▋　▉ ▊ ▋ 　 ▎ ▌▉　 ▋　▀▋ 　　 ▊　▎ ▌ ▊
　 ◥█▓▀▉　▓▊▐▂▄▃▌▄▊ ▋ ▊　 ▍ ▋█▃▲▄▂▲ 　▍　▋　▍　▼
　　█▓　▼ ▓▋▐◣▃▅▆▆◣▃▌ ▊　▌ ▊█▃◢▆▆▅◣▋ 　▌ ▐　 ▌　▲
　　◥▇▓ 　▌ ▀▌▐▀◣ ▀▓▅　▀◣▋ ▋ █◤▀　▀▓▅ ◢▋　▲　▍ ▋　▓▌
　　　█▓　 ▍　▐▀◣ 　 ▀▀　　　 ◥▊▼ 　　　▀▀　 █▃▀▋▐▅▋　▓▌
　　　 █▓◣▲ 　▓▄　　　　　　　　　　　　　　　█▀　▓　▓▋▃▓▌　それはらめ。
　　　　▼▀█▓▅▓▀◣　　　　　　▌　　　　　　◢▀　▅▓▆▓ ▀▓▉
　　　　　　　█▓█▓▆▃　　　　　 ▀　　　　　　　▄▆▓▓█▓ 　▓▉
　　　　　　　█▓▀▆▃▀◣▂ 　　 ▄▂▂▂　　　　◢▀▃▓▓█▀ ▃▓▀
　　　　　　　　▀▓▃▀█▅▃▂　　　　　　　　　▄▆▀　█▀　 ▼
　　　　　　　　　▼▀◣ ▀██▃　　　　　　　　▃▆▀▃▆▀　▅▀

170:名無しさん＠お腹いっぱい。
07/01/11 00:28:57 UOr1IIXo0
3.98a3以降では--vbr-newがデフォルトになってるとのことですが
-V2を選択する場合には-V2 --vbr-newと設定する必要がないということでしょうか？

171:名無しさん＠お腹いっぱい。
07/01/11 00:40:43 IuuHFdeK0
>>170
そうらめぇ
-V2 ＝ -V2 --vbr-new

172:名無しさん＠お腹いっぱい。
07/01/11 00:52:55 UOr1IIXo0
>>171
ありがトー
-V2 --vbr-newと設定しても問題はないとですか？

173:名無しさん＠お腹いっぱい。
07/01/11 01:15:37 IuuHFdeK0
>>172
おｋらめぇ

174:名無しさん＠お腹いっぱい。
07/01/11 02:22:12 qiZsFZmf0
らーめんうめぇ、略してらめぇぇぇぇぇ！！！

175:名無しさん＠お腹いっぱい。
07/01/11 06:21:41 16tVVj3f0
無理矢理はらめぇ！１

176:名無しさん＠お腹いっぱい。
07/01/11 11:41:57 FLRIdteJO
相変わらず変なスレなのでありんす

177:名無しさん＠お腹いっぱい。
07/01/11 16:25:42 Nbx+UDdl0
RareWares復活ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

178:名無しさん＠お腹いっぱい。
07/01/11 18:22:05 C0UGBhhG0
開発者の外人達が、このスレでらめぇえええええええ！と叫んでるのを見たらなんと思うだろうか

179:名無しさん＠お腹いっぱい。
07/01/11 18:31:29 9VWCnpKX0
らめぇえええええええ！と叫ぶ

180:名無しさん＠お腹いっぱい。
07/01/11 18:40:39 0Q1VHRfs0
exciteの日英翻訳を試してみたが、「らめぇ」はスルーされるのな。

181:名無しさん＠お腹いっぱい。
07/01/11 18:46:36 IuuHFdeK0
そろそろ、このスレのマスコット「らめぇ」を作ろうと思うんだが

182:名無しさん＠お腹いっぱい。
07/01/11 18:56:14 0Q1VHRfs0
こんなのか?
通常
　mmm
　l a al
　 L e

正面
　mmm
　la al
　l　e. l

笑顔
　mmm
　l A Al
　l　 e

183:名無しさん＠お腹いっぱい。
07/01/11 19:08:06 r2gv99l70
一番いい音を配布しているのはレアーワレズでＦＡ？

184:名無しさん＠お腹いっぱい。
07/01/11 19:08:45 r2gv99l70
間違えた。
一番いい音質のLAMEをね。

185:名無しさん＠お腹いっぱい。
07/01/11 19:09:48 De+WUuDL0
ら、らめぇ

186:名無しさん＠お腹いっぱい。
07/01/11 19:17:46 uolT3Uz20
どういう理屈だw

187:名無しさん＠お腹いっぱい。
07/01/11 19:54:03 De+WUuDL0
よくrarewaresの名前がでる→何かしら理由があるはずだ→きっと一番Lameの質が良いんだ！

こうだな

188:名無しさん＠お腹いっぱい。
07/01/11 20:00:39 8TP5/yqv0
ウチのLAMEは活きが違うよ

189:名無しさん＠お腹いっぱい。
07/01/11 20:07:53 X/pX6Nwv0
うちのLAMEは5年寝かせたからな
昨日今日のLAMEたあ熟成が違うよ
若いLAMEなんざMP3が青臭くてよー

190:名無しさん＠お腹いっぱい。
07/01/11 20:09:12 Nbx+UDdl0
そんなこといって、ききLAMEしたら違いなんて分からないんじゃないの？

191:名無しさん＠お腹いっぱい。
07/01/11 20:12:44 De+WUuDL0
ネタにマジレスかよ

192:名無しさん＠お腹いっぱい。
07/01/11 20:28:17 Nbx+UDdl0
書いた後でそう思ったけど一応ネタだよ！！

193:名無しさん＠お腹いっぱい。
07/01/11 20:33:54 CnNOFJky0
3.97のstableって、どれ落としてもLameACM.infがないんだけど、
3.96.1に上書きして平気？

194:名無しさん＠お腹いっぱい。
07/01/11 20:37:39 oL++30Lw0
それもネタか

195:名無しさん＠お腹いっぱい。
07/01/11 21:25:46 +NsmyiL60
>>163
いえだめです。浮動小数点演算を使っている限り。

>>164
ええ、だから順番が変わらないように書けばいいわけじゃないんですか？

>>165
それを言い出したらエンコーダーなんてlameだろうがなんだろうが
どれでも一緒ってことになりますね。

196:名無しさん＠お腹いっぱい。
07/01/11 21:28:11 +NsmyiL60
まあ、とにかく開発者達がリファレンスとして使ってるバイナリが
どれなのかは知りたいところですね。

とりあえあずそれだけはちょっとは検証されてるってことですからね。

197:名無しさん＠お腹いっぱい。
07/01/11 21:45:02 uzPsGT9i0
しいて言えばソースに同梱されているMakefileや、プロジェクトファイルを
全く変更せずコンパイルしたのが公式なのかもしれない。

198:名無しさん＠お腹いっぱい。
07/01/11 22:00:44 9kEPGMT40
>>195
順番が変わらないように書く=コンパイラに最適化をさせない

>>196
考えるまでもなく自分の環境でコンパイルしたものだと思うが。

199:名無しさん＠お腹いっぱい。
07/01/11 22:18:45 YMaQiE3t0
>>151
エンコードが速くなる。

> ところでバイナリによってエンコード結果が違うことがなぜ
> あなたにはそれほどまでに困ることなんですか？
いや、全然困ってないよ。
だからバイナリ違ったら出力ちがって当たり前だといいたいだけ。
同じバイナリでも実行環境によってどの拡張命令が使われるのか違うんだぞ。

>>152
先に検証してから言えよ。
ABXテストくらい出来るだろ?
キラーサンプルあるなら出せよ。

> いいえ、不毛ではありません。デコーダ間で結果が違うのは
> デコーダがMP3の仕様を満たしてないとかが原因かもしれません。
デコーダが仕様を満たしていないからといってエンコーダが出来ることは何も無い。
LAME開発者がなにかしたところでMP3再生に使われるファームウェアを書き換えるなんて
不可能だからな。
ソフトウェアのことしか考えてないようなところもお前は頭が悪いな。

> ＞可逆圧縮ではないのですよ?
> だから？
処理系によって結果が違うようなものをあれこれ考えても無駄ということだ。

200:名無しさん＠お腹いっぱい。
07/01/11 22:19:36 YMaQiE3t0
>>154
C言語で書く限り浮動小数点演算の精度の保障は出来ない。
精度保障された浮動小数点ライブラリを使わないかぎり
同じソースから同じオプションでコンパイルされた物でも
デコード結果が一致することは期待できない。

>>158
開発者っていっても一人じゃないだろ、誰かがRarewaresが公式と思っていても
他の開発者は非公式だと思ってたらどうするんだよ。

リポジトリやリリースバージョンのソースに関しては公式というのは皆一致してるだろうがな。

201:名無しさん＠お腹いっぱい。
07/01/11 22:19:54 YMaQiE3t0
>>195

> いえだめです。浮動小数点演算を使っている限り。
CPUに依存しない浮動小数点ライブラリを使えば今言っているような精度の違いは
一切排除できる。
そのかわり速度がいまより遅くなることはあっても速くなることは無いだろう。

> ええ、だから順番が変わらないように書けばいいわけじゃないんですか？
順番が変わらないでも空きレジスタの状況によって変数がレジスタ(アキュムレータ)に
入るか、メモリに置かれるのか違ってくる。
というか、順番変えないでも処理系によって演算精度違うんだから
x86しか考えないで物をいうな。
なぜエンコードのオプションは無視してコンパイラのオプションに
こだわるのかが全然わからない。

> それを言い出したらエンコーダーなんてlameだろうがなんだろうが
> どれでも一緒ってことになりますね。
浮動小数点の精度だけでいえばどのエンコーダでも一緒だろ。
午後のこ～だみたく積極的に拡張命令使うところもあれば
C言語の枠内だけでコンパイラの最適化にまかせるところもあるだろう。
だが、浮動小数点の精度が音質にどこまで影響するのかきちんと
示せない限り、そんなことを何人もの人が調べる必要は無い。
-q0と-q2の違いのほうがまだ調べる価値あるわ。

>>196
みんながx86のICLとgccを持っているわけじゃない。
使っている処理系が違えば検証できない。
検証するのはソースを変えてABXテストするくらいだろ。
リファレンスのバイナリなんていうのはWindowsの世界くらいのものだろ。

202:名無しさん＠お腹いっぱい。
07/01/11 22:29:50 r2gv99l70
で、結局、一番いいのはどこ？

203:名無しさん＠お腹いっぱい。
07/01/11 22:31:35 YtZC8DwR0
>>202
お前の心の中にあるさ

204:名無しさん＠お腹いっぱい。
07/01/11 22:41:55 qaYKAo3i0
らめぇぇぇぇぇ

205:名無しさん＠お腹いっぱい。
07/01/12 03:19:27 G/UQ7tFw0
3.97stableの駄目文字対策版って無いのかな？

206:名無しさん＠お腹いっぱい。
07/01/12 03:22:44 X70VcFqb0
駄目←これすごく重要ね。

207:名無しさん＠お腹いっぱい。
07/01/12 05:11:13 eGJ61IPF0
3.98a11ってエンコード早くね？

208:名無しさん＠お腹いっぱい。
07/01/12 18:03:06 VU5eNVzv0
>>205
それより3.98 stableらめぇ

>>206
らめぇ

209:名無しさん＠お腹いっぱい。
07/01/12 19:48:55 8MOPK1oN0
2ch閉鎖らめぇ

ユーザーショック…２ちゃんねる、再来週にも強制執行
URLﾘﾝｸ(www.zakzak.co.jp)

210:名無しさん＠お腹いっぱい。
07/01/12 19:59:03 NKS45Ogg0
大勢のユーザーの迷惑を顧みず、自分の事しか考えないDQNな男性(35)。
こういうDQNな人間が裁判を起こすと恐ろしいね。

211:名無しさん＠お腹いっぱい。
07/01/12 20:08:20 vKtHuFT50
やっと脱2chができるらめぇぇぇ！

212:名無しさん＠お腹いっぱい。
07/01/12 20:10:12 VU5eNVzv0
>>210
DQNはどっちらめぇ
もし閉鎖しても、他所行けばいいらめ

213:名無しさん＠お腹いっぱい。
07/01/12 20:13:48 XDo1+Ylu0
>>210
まさにDQN乙

214:名無しさん＠お腹いっぱい。
07/01/12 20:40:44 136oAHbF0
誰が赤の他人の事考える奴居る
特にお前ら見たいなデブオタは社会に出ると即いじめられるよ＾＾

215:名無しさん＠お腹いっぱい。
07/01/12 20:44:14 kQmu9vML0
会社員(35)は間違いなく地獄行き。

216:名無しさん＠お腹いっぱい。
07/01/12 22:08:37 K4lxZwTz0
誰か地獄少女に頼んでよ

217:名無しさん＠お腹いっぱい。
07/01/12 22:09:53 XDo1+Ylu0
というかおまえらそんなことよりLAME4の話をしろよ

218:名無しさん＠お腹いっぱい。
07/01/12 23:26:28 /TDAWUZP0
らめぇ

219:名無しさん＠お腹いっぱい。
07/01/13 00:11:43 oQhmdOZa0
またクズが裁判起こしたのか。

220:名無しさん＠お腹いっぱい。
07/01/13 07:48:28 EWe2y9DP0
会社員(35)は玉子。

221:名無しさん＠お腹いっぱい。
07/01/13 09:51:45 tNAgTHr/O
とみながは今LAME4を作ってるのか？

222:名無しさん＠お腹いっぱい。
07/01/13 12:55:42 cANbv8Hz0
さて、自演疲れないしまたやつか

223:名無しさん＠お腹いっぱい。
07/01/13 16:25:21 eSO/0iHA0
--resample でmpeg2.5の160kbpsビットレートで作成しようとしても、できないのは仕様？
どこかのページにmpeg2.5の対応ビットレートは8,16,24,32,40,48,56,64,80,96,112,128,144,160と
書いてあったので、できないのはおかしいと思った次第であります。
どうなんでしょうか？

224:名無しさん＠お腹いっぱい。
07/01/13 16:51:29 29qzm13D0
できるけど。
--resample 11.025 -b 160
とか。

225:名無しさん＠お腹いっぱい。
07/01/13 18:02:19 2/1brT5O0
>>223
サンプリングレートが高い奴だと駄目
もともとmpeg2.5ってのは低サンプリングレートに対応するための拡張規格だから

226:名無しさん＠お腹いっぱい。
07/01/14 01:25:51 d1aJxejh0
>>207
オプション-V 2で同じソースをエンコードして比べてみたが3.98a11のほうが遅い。
出力されたファイルのサイズも--vbr-newの場合で、3.97だと227kbpsになるものが
3.98a11だと237kbps。

環境: Pentium4 Northwood HT有効
バイナリ: Rarewaresから落としたlame3.97.zipとlame3.98a11.zip

同じバイナリで--noasm mmx,3dnow,sseを付けたのと付けてないので
出力を比べたがMD5,SHA-1まで完全に一致した。
速度の面でも特別遅くなるわけではないようだ。
noasmの有無よりもvbr-newとvbr-oldの違いのほうが顕著。

ちなみにCBR 320kbpsでエンコード速度のベンチマークをしてみたら
Lameがだいたい22秒のところを午後のこ～だ3.13で-q 0だと2秒。
-q 0でも8秒弱だから、速度重視ならやっぱり午後のこ～だがいいみたい。

227:226
07/01/14 01:27:37 d1aJxejh0
訂正、-q 9で2秒。-q 0で8秒弱ね。

228:名無しさん＠お腹いっぱい。
07/01/14 07:59:54 WuDTbcVM0
VBRでエンコードする時って2passできないの？

229:名無しさん＠お腹いっぱい。
07/01/14 08:19:06 OKGOMsFX0
>>228
nspsytune2 という 2pass プロジェクトがあったけど数年前にぽしゃった.
理由は作者が匿名掲示板に中傷をかかれてやる気がなくなったから.

230:名無しさん＠お腹いっぱい。
07/01/14 08:32:17 WuDTbcVM0
　　_, ._
（　ﾟ Дﾟ）

231:名無しさん＠お腹いっぱい。
07/01/14 10:31:35 aVkC++Ii0
ひどい掲示板だな

232:名無しさん＠お腹いっぱい。
07/01/14 10:52:29 Y5kuwE460
ここだったりしてｗ

233:名無しさん＠お腹いっぱい。
07/01/14 11:12:44 OgT7NhBs0
いや、たしかストーカーやってたんじゃなかったか？

234:名無しさん＠お腹いっぱい。
07/01/14 14:10:27 XQM+1a+S0
中傷されたくらいでやめる奴が立ち上げた時点で失敗なプロジェクトだな
むしろ口実にでも使われたんじゃないだろうか
経緯全く知らずに言うけど

235:名無しさん＠お腹いっぱい。
07/01/14 14:42:13 KFR7EoLX0
じゃgpsychoでも使ってろ

236:名無しさん＠お腹いっぱい。
07/01/14 15:31:16 DaP3rvM70
ここの>>605とかスラドのIRCの事だな。
URLﾘﾝｸ(pc.2ch.net)

237:名無しさん＠お腹いっぱい。
07/01/14 15:57:30 9j5sy3rP0
ドリスみたいな服着てる女子高生がいたらムラムラくるのは聖上だと思う。

238:名無しさん＠お腹いっぱい。
07/01/14 16:14:36 qhwdMOZy0
あの人の日本人嫌いはやっぱりとぅーちゃのーと言う掲示板が原因だったとですか！
とぅーちゃのーという掲示板はやっぱりとんでもないところですね！

239:名無しさん＠お腹いっぱい。
07/01/14 16:23:11 3OuoV6PQ0
>>224
>>225
回答サンクス。
なるほど。ということは入力元のサンプリングレートが高い(44,1khzとか)をmp3g2.5とかの規格に無理に変換しようとするから
160kbpsとかにできないわけ？
入力元のwavがはじめからmpeg2.5に適したサンプリングレート(8,11,025,12khz)ならビットレートも160までできる。
そういう解釈でOK?

240:237
07/01/14 16:34:18 9j5sy3rP0
今気づいた。誤爆した…。

241:名無しさん＠お腹いっぱい。
07/01/14 16:38:14 Ac2T0fEc0
>>239
2.5に適したサンプリングレートというのとはちょっと違ってて、
8, 11.025, 12kHzのサンプリングレートの為の規格がMPEG2.5
という位置付け。

16, 22.05, 24kHzの場合は MPEG2

242:名無しさん＠お腹いっぱい。
07/01/14 16:53:43 3OuoV6PQ0
>>241
丁寧な回答サンクス。
むー224のいったとおりで試したがやはり無理。
入力元はMicrosoft PCM, 16bit, 44100Hz, 2ch, 1411Kbpsだが・・・
コマンドプロンプトが立ち上がるもののすぐに終了。-b 64以下なら変換できるが。
頭悪い回答ですまん。

243:名無しさん＠お腹いっぱい。
07/01/14 20:06:26 kWR/B1lB0
4.0らめぇ・・・

244:名無しさん＠お腹いっぱい。
07/01/14 20:26:09 ruz/qalO0
>>198
>順番が変わらないように書く=コンパイラに最適化をさせない
ところがいわゆる公式ソースそのままでビルドすると最適化もりもり
なんですよね、これが。

>考えるまでもなく自分の環境でコンパイルしたものだと思うが。
それってどうやって確認しました？

245:名無しさん＠お腹いっぱい。
07/01/14 20:32:26 ruz/qalO0
>>199
>エンコードが速くなる。
なるほど。これは確かにメリットではありますね。

>先に検証してから言えよ。
たぶんしないと思いますよ。それこそ不毛だし。
出力ファイルの解析(frame analyzerとか)はやるかもしれません。

>デコーダが仕様を満たしていないからといってエンコーダが出来ることは何も無い。
いえ、論点が違いますがな。私は「デコーダの実装の差をエンコーダで
埋めるんだ！」などとは書いてません。同じファイルをデコードして
差があるのは単なるデコーダの実装の差かも知れないって言ってるだけです。

>ソフトウェアのことしか考えてないようなところもお前は頭が悪いな。
つうわけで頭が悪いのはお前のようです。

>処理系によって結果が違うようなものをあれこれ考えても無駄ということだ。
よかったですね。ところが無駄だと思わない人もいるということで。

246:名無しさん＠お腹いっぱい。
07/01/14 20:32:40 9ybXbFI00
もういいよ・・・鬱陶しいなぁ

247:名無しさん＠お腹いっぱい。
07/01/14 20:36:36 vNT/Cn9A0
院展シティステレオの実装まだぁ～？

248:名無しさん＠お腹いっぱい。
07/01/14 20:38:22 KFR7EoLX0
最適化させたくなけりゃ自分でconfigure書き換えればいいだけだろ...そんなこともできんのか

249:名無しさん＠お腹いっぱい。
07/01/14 20:38:46 ruz/qalO0
>>200
>C言語で書く限り浮動小数点演算の精度の保障は出来ない。
IEEE754とかに準拠したコンパイラを使い、準拠した計算を
行うバイナリを吐くようなコンパイラオプションを指定してもですかね。

>開発者っていっても一人じゃないだろ、誰かがRarewaresが公式と思っていても
>他の開発者は非公式だと思ってたらどうするんだよ。
どうしましょう。つうかそもそも「公式だ」とかいい加減なことを平気で
書いてしまうところが怪しいですよね。なぜ「気にするな、大丈夫だ」とか
根拠なしに書いてしまうんでしょうねぇ。

「本当に有為でないか検証はだれもしていない。」とかならわかるけど。

次ページ