LAMEコマンドラインオプションを語れ！その42
■ このスレッドは過去ログ倉庫に格納されています
MP3エンコーダーではない何かであるLAME(LAME Ain't an MP3 Encoder)のスレッドです。
[前スレ]
LAMEコマンドラインオプションを語れ！その41
http://anago.2ch.net/test/read.cgi/software/1337093460/
[関連サイト]
本家
ttp://lame.sourceforge.net/
ソースコード
ttp://lame.cvs.sourceforge.net/viewvc/lame/lame/libmp3lame/lame.c?view=log
海外掲示板・wiki
ttp://www.hydrogenaudio.org/
ttp://wiki.hydrogenaudio.org/index.php?title=LAME
バイナリ
ttp://lame.bakerweb.biz/
ttp://www.rarewares.org/mp3-lame-bundle.php
ttp://www.free-codecs.com/LAME_Encoder_download.htm
★まとめサイト★
http://www.geocities.jp/buritora2004/lame/ 盗人？
AACをサポートしてないハードをたまに見かけるから >>412
EACから使えるフリーなAACエンコーダでおすすめな物があれば、ご教授くださると助かる
>>414
マルチコアにると、シングルコアに比べて音質がどうしても劣化するからって事で本家は辞めてたんだっけか
エンコード速度を重視したいのなら午後を使うしかないかと qaacとかFDKのとか
マルチコアに関しては単に開発者の能力不足 foobar2000なんかだとCPUコア分の複数曲を同時エンコしてくれるからそれで十分
おいらのi7-4800MQならシングルタスクでもあっという間だし >>417
LAME使うならfoobarだよねえ
今更午後とか言ってる情弱さんがいることに驚く >>420
LAMEとの関係ではfoobar2000もフロントエンド ごめん 「Lame Front-End」 使ってるけどｒｙ って意味 並列処理はできないけどrazorlameに安心感がある >>418
こんなのあったんだ
素のlameばかり見てたのでずっと気付かなかった
出来上がりのバイナリは一致するのかな もしかしたら頓珍漢な事言ってるかもしれんがすまん
今までV0がLAMEの持ってる一番品質の良いアルゴリズムだと思ってたんだけどさ
よくよく考えるとCBR320kbpsでのエンコードってV0のアルゴリズムより品質が高いもの(特に情報の少ない時間では)を使ってるって事なんだよね？
まさか全部パディングしてるわけじゃないだろうし…(そもそも今でもパディングなんてやってるのか？)
だとしたらVBRでもそのV0よりも品質の高いアルゴリズムを使った(平均320kbps程度かそれ以上をターゲットとした)エンコードを用意できると思うんだけど、
それが用意されてないのはなぜなんだろう mp3の最大ビットレートは互換性無視しない限り320kbps MP3の規格上、ビットレートを320kbpsより大きくすることは出来ない。
（--freeformatによって出来るMP3は規格外のMP3であり、再生出来るデコーダは極めて少ない）
なのでVBRで平均320kbpsということは、全てのフレームで320kbpsを使うということであり、
それは最早VBR（Variable BitRate）とは言えないだろう。 あーなるほど規格上の問題か、ありがとう
ところでV0でエンコードすると音によっては320kbpsを超える圧縮結果が出来たりすると思うけど、
そういう場合は一時的にV1にでも下げて再計算してるのかな MPEGで配られてる規格書見ればいいと思う
（君に理解できるかは知らない） 320kbpsフレーム(とリザーバ)に入りきらなかったら量子化パラメータを変えて再圧縮するだけ 今更可変と固定の質問てなんだよ
しかも専門的な話かとおもいきや全く理解してない頓珍漢 >>441
ゴメン、英語見ただけで読む気も調べる気も無くなる LAME(3.99.5)の--preset standardで出力したmp3の再生時間がプレイヤーによっておかしくなるんだが何かオプションがいるのだろうか --preset standardなら-V 2でいいやん VBRだと再生時間の表示が狂うとかなんとか上の方に書き込みあるよ 時間が狂うのはプレイヤーじゃなくてコーデック依存だった気がする。
LameACMを入れて優先順位を一番上にすれば直りそうな気がする。 プレイヤーが使ってるデコーダ依存にしてるだけだと思う
コーデック使ってないのだってある訳で
デコーダではなくタグ情報とかもせ解析DLLみたいなもの使ってたりするのもあるけど VBRだとxingヘッダかID3のTLENかどちらかで判断することになる
どっちも読まなければファイル全体を解析しないと正しい再生時間は分からない lameの標準入力にwavデータを入力してヒストグラムを表示しながら
変換するオプションってないですよね？ 無い無い
あってそんな事ができても、表示(変換速度)が早すぎて全然わかんないと思うの やっぱり無いですよね。
変換中何の表示もされないから、きちんと変換されてるか不安になる 100MBくらいのwaveファイルを、コマンドライン-V0だけなLAMEに食わせてみたら？ >>456
type in.wav | lame -V0 - out.mp3
でヒストグラムを表示できたらなと思ってます。
type in.wav は flacとかをwavに変換して標準出力に出力するプログラム(ffmpegとか)の代わりです。 どのVerからデフォルトでヒストグラムが出なくなったんだっけ？ バッチ書いてtemp.wavとかを出力してlameの引数に食わせた方が早いんじゃ この修正が入った後は--briefとか付ければstdinからエンコードする時も表示されるようになるはず
https://sourceforge.net/p/lame/bugs/429/ うちの64bit版な3.99.2.5だと普通に出てる LAME 64bits version 3.99.5
だけど--briefをつけても出ない
ダウンロードしたのを使ってるけどビルドの仕方で違うのかな？
mp3ファイルは問題なくできてるからまぁいいかな >>465
ありがとう、ソースダウンロードしてビルド頑張ってみる >>465 >>462の所からたどってダウンロードした3.100だと --briefつけて表示された。
でもなんとかビルドできたのが32bit版なので変換が遅い。
>>467
やっぱり表示されない 3.99だと環境もあるのかも・・・ win8だからかな 個人的には可逆にしないならMP3で十分だなあ。
--preset insaneでも劣化してると分かる音源に出会うことは
少なくとも自分が聴く音楽の範囲では無いし。 >>472
変換にMDCTだけを使うAAC-LCは、サブバンド + MDCTのMP3より高圧縮を実現しつつデコードが速いよ 遅い早いじゃない
軽いかどうかってんだよ
Z80でもﾓｰﾏﾝﾀｲってくらいにな Z80だとリニアPCMをそのまま再生する性能しか無いだろう 最初のつぶやきから半年か
https://twitter.com/kamedo2/status/743807219804758017
お疲れさまでした
kamedo2さんのテストは、フォーマット・エンコーダ・エンコードオプション・
ビットレートのどれかが個人的には「なぜ今それ？」というチョイスだったり、
追認にとどまるものだったりして、開発者ならともかくユーザーとしては
結果的には参考にしていないものが多いな
でも有益で珍しい存在ではあるし、TOEICが高得点で読みやすい英語を書いて
くれるので、これからも続けてほしいなとは思う >>477のテストの後もあまり専用のスレが立ったり伸びたりしてないね
https://www.google.co.jp/search?as_q=helix&;as_sitesearch=hydrogenaud.io&as_occt=title
確かに無視に近いかも
今回のようにLAMEより高いスコアを出すこともあるのにね LAME 大敗北じゃん
誰だよ敵なし言うたの
HELIXに乗り換えるわ まるで死後になって評価された画家のよう
かわいそうなヘリックス >HELIXに乗り換えるわ
>>478に書いてあるように一長一短なので気を付けてね うわーは本当にショックを受け、ヘリックス（興）がうまくいった。 GNRの新しいアルバムが出ただけでなく、 Xing（Helix）はLAMEを上回っています。 地獄は今ほとんど寒いです HelixのENC_DELAYの値が44100Hzの時1680サンプルらしいと言うのは調べたが、PADDINGが多すぎるせいか、
ギャップレス再生ができないな 406 名前：番組の途中ですがアフィサイトへの転載は禁止です (中止 Sa96-B7Yb)[sage] 投稿日：2017/02/14(火) 14:36:02.16 ID:AxKM1to4aSt.V
ヘッドホンに金をかけたいんで320kbsのmp3音源全量flac化てのをやってる
レンタルCDから15年くらいかけて集めた奴全量なので結構きついが
暇つぶしになっていい、唯一の趣味ともいえる
なおmp3の320kbsとflacの違いは全くわからない ついに最終段階に来た。
LAMEもずっと更新されてないし、320でエンコし直すことにしたわｗ
次エンコし直す時は、MP3を卒業する時だなｗ >>490
カーオーディオで聴くのが主な目的だが、古いのでMP3とWMAしか対応してないんだわ。 >>492
俺は自宅用は FLAC、車用は m4a(ipod+カーナビ)にしてるな。
車で聴くならあんまり音質は気にしなくて良いんじゃないか。
どうせロードノイズでかき消されるのだから。
ちなみに、最初は mp3(LAME) にしていたが、途中から m4a に変えた。
わざわざエンコし直してはいない。
そのうち車でも FLAC が使えるようになれば良いけど、ipod じゃ見込みは薄いか。
って、こんなこと書いたらスレ違いになっちゃうね。 ハイレゾ - LAME -> mp3 と
ハイレゾ - ？ - > CD - LAME -> mp3 だと
どっちがデータが小さくなるんだろ？
同じ値段だとCD買うか配信買うか悩む LAMEを何だと思ってるんだコイツ
バーカ、アホ、間抜けと罵倒して良いレベルだな 48kHzのハイレゾならいいけど、それを超えるサンプリング周波数の場合、
MP3に圧縮する際にリサンプルまでしなければならなくなるよ。
もっとも48kHzのハイレゾって言ったら量子化ビット数以外CDと殆ど変わらない気がするが。 >>495
あっそうか、CDは44.1kHzだからCDからmp3作った方が小さいデータになるのか。
ありがとう。
しかも自分で作ったバッチファイル見直したらffmpegでリサンプルしてた、そこで気が付け俺 何と比べて同じって聞いてるのか分からないけど、、、
設定どうこうで最終的にCBRとVBRとのファイルサイズが完全に同じになる事はある 元が96kHzの音源なら、48kHzにリサンプリングしてMP3にエンコードした方がプリエコーはましになると思う。
ただ、LAMEが44.1kHzと48kHzで同じレベルで最適化ができている前提の話であるが。 MP3って大抵20kHzくらいでローパスフィルタ入るから元が44.1kだろうが48kだろうが大差ない気がする 周波数毎のプリエコーの違いはこれ
https://hydrogenaud.io/musepack/klemm/www.personal.uni-jena.de/~pfk/mpp/timeres.html
>>500
sfbの対応する16kHzくらいまでしか効率的に圧縮できない規格だからしょうがないね >>500
元と変換後の周波数が違う(48⇔44.1)と、1割ほど余計な事してその分＋αのデータ量が無駄になってるって事になるからなんかヤダ バーカ、アホ、間抜けと罵倒されてる>>493です。
同じ曲のハイレゾ版とCD版 [サンプリング周波数が違うの忘れて] mp3にした時どっちがファイルサイズ小さくなるんだろ？
と思って書き込みました。すみません。
>>498
CBRだったらハイレゾでもCDでも同じ曲だったら同じファイルサイズになるように
VBRでもハイレゾ、CDにかかわりなく同じ曲なら同じファイルサイズになるのかなーと
たぶんVBRだとCD版の方が小さいファイルサイズになりそうな気がするのですが >>503
ハイレゾ→44Kor48Kダウンサンプリングの過程or方法で、CD版(44K)より小さくなる場合もありえる(´･ω･`)
まあダウンサンプリングが綺麗にできてれば元ハイレゾ音源の方が最終的にサイズ大きくなるとは思うけど どちらも信号帯域が20kHz以下という条件なら
48kHzソースの方が周波数領域での非ゼロなbinが多くなって圧縮しやすくなるんじゃないの ×非ゼロなbinが多くなって
○非ゼロなbinが少なくなって >>503
128ｋｂｐｓとか320kbpsのkbpsの意味を調べてみれ 同じレート設定前提で話してると思ってたけど違うの？それとも質問の意味分かってなくて書いたの？ 久々にＬＡＭＥで遊んでみた
3982→3995にして変換したんだけど、
96kbps選んでも何をしても320kbpsで出力されちゃってﾜﾛﾀ・・ どうせ変更点把握しないまま使った設定ミスなんでしょ >>508
基本的に同じ曲で同じ長さなら、ソースが違っても大差ない結果になるってどうしてわからないの？バカなの？
人が文意をとれないとかコケにする前に自分の低能さを知れよ池沼 大差ないって事は、多少の差はあるって事で、その多少の差を言ってるんだと思うんだよね(同じじゃない) ■ このスレッドは過去ログ倉庫に格納されています
