09/12/12 16:56:10 svJrdkSK0
AACだってエンコーダによって音質はかわる。
iTunesのAACエンコーダは非常に良い。特に最近のiTunesのものは改良が加えられている。
ただしiTunesのMP3エンコーダは評判が悪い。
WMAはAACに勝る点は何一つ無い。互換性とか考えるとMP3以下の糞。
まあ，不安ならロスレスで。
655:名無しさん＠お腹いっぱい。
09/12/12 17:51:57 2+EthQsG0
＞ただしiTunesのMP3エンコーダは評判が悪い。
最近はそうでもねえです
URLﾘﾝｸ(www.listening-tests.info)
656:名無しさん＠お腹いっぱい。
09/12/12 17:57:17 9JhqAZ8e0
まぁHE-AACのことなら正解だけどね＞高レートが不得意
657:名無しさん＠お腹いっぱい。
09/12/12 21:28:22 CVSTgd170
>>654
同じビットレートでwmaとaac,mp3聴き比べたことあんのか？
160kbpsくらいだとaacもmp3もカスカスだぞ
658:名無しさん＠お腹いっぱい。
09/12/12 21:56:59 svJrdkSK0
>657
カスカスなのはあなたの耳
659:名無しさん＠お腹いっぱい。
09/12/12 21:59:48 DGolDip+0
URLﾘﾝｸ(web.archive.org)
昔のpublic listening testの結果だが、WMAはフォローしようがない。
(この後、WMA Proで巻き返すが、これは規格上別物)
660:名無しさん＠お腹いっぱい。
09/12/12 22:12:54 6sw/FzsL0
128kbpsより大きいレートだと公開テストしても
まともな結果が出ないから無意味なんでしょ。
ロスレスの試聴テストがオカルトの領域なようにね
（圧縮率やエンコ・デコ速度の比較だけなら意味あるけど）
661:名無しさん＠お腹いっぱい。
09/12/12 23:18:17 tZHkmdgP0
なんでビットレート厨ってこれほどまでアホなの？
662:名無しさん＠お腹いっぱい。
09/12/12 23:31:41 BVmJDeu80
wma(笑）
663:みのる
09/12/12 23:37:48 jPuNcXP00 BE:2978055-2BP(3123)
カーオーディオの圧縮フォーマットをMP3の320kbpsからAACの128kbpsに変えたが、停止
してエンジンを切って聞いても違いがわからんな。容量が小さくなった分、4GBの媒体で70
枚以上のアルバムが入る。AACはなかなかいいですなぁ・・・
664:名無しさん＠お腹いっぱい。
09/12/13 00:32:32 bRdnaTQy0
>>663
それはカーオーディオだから
環境が悪いし、それを補う為に補正しまくってるし聞き分けるのが難しい
665:名無しさん＠お腹いっぱい。
09/12/13 00:34:55 kFd1+C/mP
>>654
iTunesは今でも色々改良されてんのか…
NeroAacEnc使ってんだけど、乗り換えようかなあ…
666:名無しさん＠お腹いっぱい。
09/12/13 02:31:13 6RIoLCxG0
foobarでロスレスから渡してお任せ変換出来るしね。無理やりだけど。
667:名無しさん＠お腹いっぱい。
09/12/13 12:10:41 7c3HZNXY0
>>665
お前は気づいてないかもだが、Neroもエージングでどんどん音がよくなってるよ。
だいたい1000曲エンコすると良音質で落ち着く。
668:名無しさん＠お腹いっぱい。
09/12/13 13:39:11 4nLdO8NJ0
なんてデカい針なんだ
669:名無しさん＠お腹いっぱい。
09/12/13 13:57:20 qDAxoM2l0
ハードウェアがだんだんソフトウェアに
670:名無しさん＠お腹いっぱい。
09/12/13 17:42:29 poPdMMuiO
>>669
それはあるな
昔はハードウェアエンコードが当たり前だったものが
今はソフトウェアエンコードばかりになったからな
つーか、音質はエンコーダーよりデコーダーによる違いの方が大きいだろ
671:名無しさん＠お腹いっぱい。
09/12/13 17:51:34 lspdYfLC0
んなわけねーだろ
672:名無しさん＠お腹いっぱい。
09/12/13 20:23:01 kFd1+C/mP
>>670
> 音質はエンコーダーよりデコーダーによる違いの方が大きいだろ
んなこといったらCDの意味ねーじゃん
673:名無しさん＠お腹いっぱい。
09/12/13 20:46:38 5Q8TEy3d0
そのうちCDからリップ→エンコードってなくなると思ってたけど、
CDでのパッケージ販売って、まだ当分残りそうだなぁ。
配信限定販売とかにかぎらずとも、シングルカットはDVDでのみとか、
BDシングル(not 8cm-Disc)とか出てきそうなもんなのに
674:名無しさん＠お腹いっぱい。
09/12/13 20:51:03 krMOmcHZ0
>665
正確にはエンジン部分のQuickTimeのバージョンに依存するよ。
最近の，7.6だったかなんかでも改良したはず。
675:名無しさん＠お腹いっぱい。
09/12/13 21:02:45 qDAxoM2l0
>>673
iTunes Plusを受け入れられないところが多いからな・・・
676:名無しさん＠お腹いっぱい。
09/12/14 00:13:16 JTmenn8X0
>>670
エンコーダ規格と違ってデコーダの規格は厳格だぞ
どのデコーダで再生しても全く同じ結果になる。
音が違うというならばデコーダ以外の部分の話。例えばiPodとウォークマンだったら
同じAACでも音声処理回路が違うから出音は変わるよね
677:名無しさん＠お腹いっぱい。
09/12/14 00:25:57 8PInqf0i0
いや全く同じ結果にはならんよ
678:名無しさん＠お腹いっぱい。
09/12/14 00:40:15 2pzw1yfJ0
>>677
それはバグ持ちデコーダだろ
試しにAACからwaveにデコードしてみろよ
NeroだろうがiTunesだろうがSonicStageだろうが全部バイナリ単位で一致するから
679:名無しさん＠お腹いっぱい。
09/12/14 01:29:53 8PInqf0i0
>>678
ネタで言ってるのか?
浮動小数点での処理が許される限り実装ごとの差異は避けられないよ
といっても大抵はLSBが違う程度だが
(1) iTunes
(2) NeroAacDec
(3) FAAD (FPU:SSE)
(4) FAAD (FPU:x87)
・ファイルサイズ
(1) : 6,171,260 bytes
(2) : 6,171,260 bytes
(3) : 6,176,812 bytes
(4) : 6,176,812 bytes
・バイナリ比較結果
(1) vs (2) : 計3,347bytesの差異
(3) vs (4) : 計2,058bytesの差異
まずiTunesのギャップレス再生情報を読まないFAADはiTunes、Neroとファイルの長さからして違う
ファイルの長さが同じiTunesとNeroでは実装の違いから差異が出る
実装の同じFAADでも浮動小数点演算にSSEを使うかx87を使うかで差異が出る
つまり
・paddingやencoder/decoder delayによる差異
・実装の違いによる差異
・浮動小数点演算の処理系の違いによる差異
の3点が観測可能な差異として現れる。
680:名無しさん＠お腹いっぱい。
09/12/14 01:32:40 ljOI2nCB0
デコーダディレイの差異が音質の違いとかマジキチなんだが
681:名無しさん＠お腹いっぱい。
09/12/14 01:37:57 8PInqf0i0
>>680
???
>全く同じ結果になる
>バイナリ単位で一致する
に対する反論であって、聴覚上の品質の差異には特に言及していないが。
682:名無しさん＠お腹いっぱい。
09/12/14 01:44:07 ljOI2nCB0
＞つーか、音質はエンコーダーよりデコーダーによる違いの方が大きいだろ
↓
＞どのデコーダで再生しても全く同じ結果になる。
↓
＞・paddingやencoder/decoder delayによる差異
683:名無しさん＠お腹いっぱい。
09/12/14 01:48:52 8PInqf0i0
だからそれは
>"全く"同じ結果になる
>バイナリ単位で一致する
に対する反論だっつーの 意味わかってる?
684:名無しさん＠お腹いっぱい。
09/12/14 01:55:52 9lI9aeXr0
> 音質はエンコーダーよりデコーダーによる違いの方が大きいだろ
この意見に対しての答えとしては、
>>679を見る限り、デコード時の差異と各エンコーダーによる差異とでは
エンコーダーによる差異の方が大きいと言えるのでは
まとめるとこんな感じでおｋ？
685:名無しさん＠お腹いっぱい。
09/12/14 01:58:17 8PInqf0i0
679の結果を見るまでもなくそんなのは当然の話。
686:名無しさん＠お腹いっぱい。
09/12/14 01:58:45 OYZdSttG0
は？ｗｗｗｗｗｗｗｗｗ流れ読めよｗ
お前の意見だと
・paddingやencoder/decoder delayによる差異
・実装の違いによる差異
・浮動小数点演算の処理系の違いによる差異
の３点があるからデコーダ毎に大きな音質差があると言う話になるぞ？ｗｗ
バイナリ単位で一致する云々言ってる人と音質が一緒と言ってるのは別人だしね
勝手にまとめて自分なりに解釈されても可笑しな話なんだがｗ
687:名無しさん＠お腹いっぱい。
09/12/14 01:59:43 IfY3n7du0
>>685
顔真っ赤にして必死だな
688:名無しさん＠お腹いっぱい。
09/12/14 02:08:46 8PInqf0i0
>>686
だから681を読めと。
つーかいちいちID変えて出てくんな
689:名無しさん＠お腹いっぱい。
09/12/14 02:11:45 vOXt4Ovm0
＞どのデコーダで再生しても全く同じ結果になる。
っていう言及は
＞つーか、音質はエンコーダーよりデコーダーによる違いの方が大きいだろ
に対しての反論として出てきた物であってさ。
それに対するお前の反論は、音質にも及んでいるんだよ
だから流れ読めってｶｽが
690:名無しさん＠お腹いっぱい。
09/12/14 02:18:01 6WAJRGFe0
浮動小数点演算やらの処理通したらバイナリが変わるのは当たり前
デコードの比較をするときに使うべき処理ではない（可逆でない）
691:名無しさん＠お腹いっぱい。
09/12/14 02:32:20 8PInqf0i0
>>689
だからさあ、681で音質の話はしてませんって発言者本人が言ってるのに
何度同じことを言わせるんだろうね
そもそもバイナリ比較が音質の話だと思ってしまう頭の悪さがが波形厨並み
ところで外野はどうでもいいからID:JTmenn8X0の言い訳が聞きたいんだが
>>690
当たり前だけど、整数演算でAACデコードしてるプログラムはちょっと思いつかない。MP3はいくつかあるけど。
というか使うべき処理ではないってのはどういう意味?
692:名無しさん＠お腹いっぱい。
09/12/14 05:03:54 f688dNIh0
つーか、俺は大元の>>670に、音質が明らかに違うデコーダの実例を挙げて欲しいんだが
こんなこと、実例を把握してなきゃ絶対言えないもんな
693:名無しさん＠お腹いっぱい。
09/12/14 05:26:17 kPthf92l0
>>679はまったく的外れでどうでもいいんですが…
デコーダーって浮動小数点演算使ってるの？
もしそうなら出力が違ってくる可能性はあるな。
694:名無しさん＠お腹いっぱい。
09/12/14 10:42:28 8PInqf0i0
>>693
バイナリが一致しない実例を挙げたのに何が的外れなんだ?
特に断りがない限りPC上のAACデコーダは浮動小数点演算を使っている。
こんなのは確認するまでもない常識だと思うのだが。
695:名無しさん＠お腹いっぱい。
09/12/14 10:42:45 +vSe7CV10
全然詳しくねーけど、この手の奴って大抵離散コサイン変換(DCT)
使ってるんじゃなかったか
JPEGやMPEGにしろ、MP3やAACにしろ
なら浮動小数点演算が普通に使われるんだべ
696:名無しさん＠お腹いっぱい。
09/12/14 11:04:23 8PInqf0i0
>>695
そう。ちなみにオーディオはほとんどがDCTではなくMDCT。
ただしH.264に関しては、デコーダごとの差異が出ないように
全てを整数演算で行うように仕様で決まっている。
697:名無しさん＠お腹いっぱい。
09/12/14 12:39:17 Nar4nVns0
抽出 ID:8PInqf0i0 (9回)
暇なんだな
698:名無しさん＠お腹いっぱい。
09/12/14 15:03:03 wPhvJ2vt0
デコーダによる音質の差なんてほとんどないね。
エンコーダはかなり大きな差があるけど。
699:名無しさん＠お腹いっぱい。
09/12/14 17:30:38 wZzM5BLNi
音質の話するなら再生環境かけと
700:名無しさん＠お腹いっぱい。
09/12/14 19:47:42 ugh4kZwV0
再生環境の前に耳の性能かけと
701:名無しさん＠お腹いっぱい。
09/12/14 20:48:59 3bKgiDga0
脳の性能は類推可能だ
702:名無しさん＠お腹いっぱい。
09/12/14 21:36:04 EW8oQhSF0
脳の性能が高い人間ほど、音質が悪くてもOKとも言える
703:名無しさん＠お腹いっぱい。
09/12/14 22:04:08 ae+Q5B4x0
昔はAMラジオを脳内で24bit/192kHzにアップサンプリングしておったものじゃて
704:名無しさん＠お腹いっぱい。
09/12/14 22:18:23 A9IOGGOR0
>>698
ほとんどない，と，まったくない，は大きく違うからね。
話の流れを読んで，理論上，デコーダによっても音はかわると理解した。
705:名無しさん＠お腹いっぱい。
09/12/14 22:54:30 wPhvJ2vt0
>>704
URLﾘﾝｸ(www.hydrogenaudio.org)
ここでこんな話をしたら笑われるぞ。
バグ持ちのデコーダでもない限り区別できないし。
706:名無しさん＠お腹いっぱい。
09/12/14 23:00:15 FhA2/3TY0
>>704
理論上というか、極めて静かな部分だけ切り取って、
大音量で再生すれば、現実に知覚することは可能。(mad challenge)
逆に言えば、そういう趣味がなければ気にするだけ時間の無駄。
707:名無しさん＠お腹いっぱい。
09/12/15 00:55:25 M6oi+ZeU0
実装と規格を混ぜるからややこしくなるんだよ
708:名無しさん＠お腹いっぱい。
09/12/15 02:18:40 Hfn9nOlI0
ＦＦ１３のラスボスは死骸化したセラらしい
ちなみに最後ライトニングさん死ぬってさ
709:名無しさん＠お腹いっぱい。
09/12/15 02:28:44 As1pWfN+0
>>694
＞バイナリが一致しない実例を挙げたのに何が的外れなんだ?
的外れです。パディングとかギャップレス再生による違いがあるだけでバイナリは一致しません。
当たり前です。
でも音楽そのものの部分のバイナリは一致するわけです。（浮動小数点演算による
違いがあるとすればそれを除けばですが。）
なので単純に曲ファイルのバイナリを比較するのは何の意味もありません。
というわけで論点は浮動小数点演算で曲ファイルではなくて音そのものに
違いがでてくるかってところなわけです。
710:名無しさん＠お腹いっぱい。
09/12/15 04:54:06 xolehjT70
>>709
だからさあ、音質の比較をするのにバイナリを比較するのは当然的外れだよ。
ただ、バイナリが一致しないのは当たり前なのに>>678が一致すると書いてるから
679で反例を挙げただけ。
粘着してるのは同一人物だろうけど、いい加減人のレスを読まないかね。
>でも音楽そのものの部分のバイナリは一致するわけです。（浮動小数点演算による
>違いがあるとすればそれを除けばですが。）
除くって何? なぜ「とすれば」?
679に書いたように浮動小数点演算による違いがあるので一致しません。
>なので単純に曲ファイルのバイナリを比較するのは何の意味もありません。
音質の比較にはね。679ではそんな話はしていない。
>論点は浮動小数点演算で曲ファイルではなくて音そのものに
>違いがでてくるかってところなわけです
しつこく言うけど679は音質が一致するかしないかではなく、
バイナリが一致するかしないかを書いてるだけ。
711:名無しさん＠お腹いっぱい。
09/12/15 04:59:15 xolehjT70
というか、初めにバイナリ一致の話を持ち出したのは678なんだから
的外れと言うならそっちに言ってくれよw
712:名無しさん＠お腹いっぱい。
09/12/15 06:07:25 EYDNpS7F0
> ただ、バイナリが一致しないのは当たり前なのに>>678が一致すると書いてるから
> 679で反例を挙げただけ。
引っ込みがつかなくなって
「脊髄反射で揚げ足取っちゃいました。流れ読めなくてごめんなさい」
って言えないんだね
713:名無しさん＠お腹いっぱい。
09/12/15 10:34:55 tm0Makag0
>>712
んー
バイナリ一致でなければバグと言い張る>>678は
明らかにAACデコーダについて誤った理解をしていて、
あれじゃ正常に動作しているデコーダまでバグ持ち呼ばわりしかねん
それを正すのは必ずしも揚げ足とは言えんと思うよ
しかし8PInqf0i0 = xolehjT70は言ってることは正しいが
煽り耐性が無さ過ぎだな
714:名無しさん＠お腹いっぱい。
09/12/15 10:38:46 xolehjT70
>>712
>>682で既にその旨を言ってるのに、ひたすら無視して引っ込みがつかなくなってるのはそっちでしょ
一連の流れで679の意味はAACデコーダによる音質の違いがないことの根拠として
・デコード結果が全く同じになる (>>676)
・バイナリが一致する (>>678)
ことを挙げるのは完全な誤りである、ということなのだが、いい加減理解したか?
715:名無しさん＠お腹いっぱい。
09/12/15 10:52:29 +kh9jCQCP
いい加減ウザイから両方共消えろ
716:名無しさん＠お腹いっぱい。
09/12/15 13:01:09 eweceEaG0
>>714
消えろ粘着
717:名無しさん＠お腹いっぱい。
09/12/15 14:49:43 V6t9x4OK0
うわあ人格攻撃にまで飛んじゃったよ
718:名無しさん＠お腹いっぱい。
09/12/15 15:07:00 BTGVLIdp0
波形厨より酷い者が現れたな。
719:名無しさん＠お腹いっぱい。
09/12/15 15:10:42 uDJa8yFT0
と、波形厨が申しております
720:名無しさん＠お腹いっぱい。
09/12/15 15:22:18 EYDNpS7F0
>>714
お前の言いたいことと言ってることが正しいのを知った上で >>712 を書いてる
でも論点がそれぞれ異なるやつが 2 人も 3 人もいて、本題に反駁してるのがお前だけだから
エンコーダ＜デコーダ って結論になっちゃうだろ
721:名無しさん＠お腹いっぱい。
09/12/15 19:21:01 xolehjT70
>>720
679を読んで679が「エンコーダ＜デコーダ」と結論付けようとしているように見えるなら
それこそ何も分かってないわけだが
722:名無しさん＠お腹いっぱい。
09/12/15 19:37:23 GfHPjzOB0
逆に言えば
・デコード結果が全く同じにならない
・バイナリが一致しない
以上の事実はAACデコーダによる音質の違いがあることの直接的な根拠にはならないと言える
723:名無しさん＠お腹いっぱい。
09/12/15 21:41:14 EYDNpS7F0
>>721
だから、どっちの援護もしないその立ち位置が問題だって言ってんの
ふと目に止まった嘘をただ切り捨てて放置はないだろ
言ってる意味がまだ分からないならもういいよ
>>722 で本流に戻れたからメタな議論はここまでにしとく
724:名無しさん＠お腹いっぱい。
09/12/15 22:26:07 xolehjT70
>>723
もともと援護を必要とするような命題ではない。>>670は釣りの類でしょ
ここまで荒れたのは721のような勘違いをして噛み付いてる奴がいるから。686とか
725:名無しさん＠お腹いっぱい。
09/12/16 01:29:59 eQFJ+5uA0
>>724
>>721>>686は何も勘違いしてないわけだが。
>>713
>>しかし8PInqf0i0 = xolehjT70は言ってることは正しいが
>>煽り耐性が無さ過ぎだな
同意。
なぜこういった既知外を放置できないのかね？
8PInqf0i0 = xolehjT70は自分自身が原因でスレがろくでもない話で
埋め尽くされているという事を認識するべき。
726:名無しさん＠お腹いっぱい。
09/12/16 01:50:08 kPmvY2U10
>>725
679を読んで音質に違いがあると主張してると思い込んでるんだから勘違い。
まあそもそも
>ふと目に止まった嘘をただ切り捨てて放置はないだろ
が意味不明だが。あんたはここのモデレータか何かか?
つーか、メタな議論はここまでにしとくとか言っときながら
わざわざレスしてる時点であんたも同類。
727:名無しさん＠お腹いっぱい。
09/12/16 09:23:55 Mc0LGMMZ0
で、音質に違いがあると主張してると思い込んでる人に対する
フォローはまだかね
728:名無しさん＠お腹いっぱい。
09/12/22 16:09:47 wKjv0hn70
Simple NeroAACEnc GUI 0.9
を使ってAACエンコードをしています。
オプションに
Use BePipe for input (via avisynth/dshow)
というものがあるのですがこれは何の為のオプションでしょうか？
これを有効にするとtwo-pass encodingが不可能になってしまうので
いつも外してエンコードしてるんですが前から気になっていました。
729:名無しさん＠お腹いっぱい。
09/12/22 17:50:44 fn62tVrY0
BepipeはAviSynthのDirectShowSourceというプラグインを利用して音声をDirectShowFilterで
PCMにデコードして標準出力し、標準入力可能なCLIエンコーダー(nero、LAME等)に渡すためのツール
例えばあるAVIに使われているmp3音声をaacに変換し、音声ファイルとして保存したい場合、これを使えば
AVIを動画用ツールで読み込み->音声をwav(PCM)ファイルとして保存->wavをaacに変換、保存 という作業を
SNGでAVIを指定->音声のみaac(mp4)で保存 と大幅に手間が省ける
ただし1パスしか出来ないので、ほぼ品質VBR専用
730:名無しさん＠お腹いっぱい。
09/12/22 18:31:18 wKjv0hn70
>>729
ありがとうございます。
ソースとしてwavファイルが用意できているときはあえてBepipeする必要は無いと言うことですね。
> ただし1パスしか出来ないので、ほぼ品質VBR専用
two-pass encodingできれば大変重宝できる機能なだけに残念ですね。
今後のバージョンアップの方に期待しています。
731:名無しさん＠お腹いっぱい。
09/12/23 17:17:12 a1TAIAsK0
> BepipeはAviSynthのDirectShowSourceというプラグインを利用して
いや、他のプラグイン使えますよ。
bepipe.exe --script "NicAC3Source(^%~1^)" | "neroAacEnc.exe" -ignorelength -q 0.32 -if - -of "hoge.mp4"
こんな感じで。
> two-pass encodingできれば大変重宝できる機能なだけに残念ですね。
> 今後のバージョンアップの方に期待しています。
名前の通りにパイプ使ってるんで絶対無理です。
732:名無しさん＠お腹いっぱい。
09/12/23 21:10:01 ZcLr0jn5P
2009-12-17 - Version 1.5.1.0
- neroAacEnc:
- Improved encoding of sample rates higher than 48kHz
- Solved compatibility issues with some hardware devices
- Write iTunes compatible gapless data
- Enabled preserving of very quiet high frequencies at high bitrates
- Write the encoder settings to metadata
- Executable size reduction
- neroAacDec:
- Improved error handling
- Speed up
- neroAacTag:
- Support 3GPP tags
- Support Sony Memory Stick tags
- Improved cover art support
- Improved support for files with multiple tags in different formats (ND,iTunes,3GPP,Sony Memory Stick)
- Writes iTunes tags by default, added switch to enable ND tags
URLﾘﾝｸ(www.nero.com)
733:名無しさん＠お腹いっぱい。
09/12/23 21:50:23 dmjzjCgC0
だいぶビットレートの曲ごとのバラツキが減ったな
音が良くなったかどうかなんて知らんが
734:名無しさん＠お腹いっぱい。
09/12/23 23:42:05 gzs1KSxC0
まとめてよ
735:名無しさん＠お腹いっぱい。
09/12/24 19:10:04 Ph5dBiy00
ver1.5.1.0はｖｂｒで同じクオリティーでエンコードしてもビットレートが前より大きくなるみたいだね
736:翻訳厨
09/12/24 19:38:34 kAp/UKym0
2009-12-17 - Version 1.5.1.0
- neroAacEnc:
- 48kHzより高いサンプリング周波数でのエンコードを改良しました。
- 一部のハードウェア機器との互換性問題を解決しました。
- iTunes互換のギャップレス再生用データを書き込むようにしました。
- 高ビットレート時に、非常に静かな高周波数を維持するようにしました。
- エンコーダの設定をメタデータに書き込むようにしました。
- 実行ファイル(.exe)のファイルサイズを減らしました。
- neroAacDec:
- エラー時の処理を改良しました。
- デコードスピードを改善しました。
- neroAacTag:
- 3GPPタグをサポートしました。
- Sonyメモリースティック用のタグをサポートしました。
- ジャケット画像サポートの改良をしました。
- 異なるフォーマットで書かれた複数のタグを持つファイルのサポートを改善しました。
(ND、iTunes、3GPP、Sonyメモリースティック)
- デフォルトでiTunesタグを書き込むようにしました。
NDタグの書き込みのON・OFFを指定するオプションを追加しました。
737:名無しさん＠お腹いっぱい。
09/12/25 19:10:41 WESgH+su0
人柱どものレポートはまだかね
738:名無しさん＠お腹いっぱい。
09/12/25 19:20:35 P/Lpnpv8O
AACは音質いいね
AAC128kbpsを、MP3の128kbpsと比べると明らかに良い
MP3の192kbpsと比べると、微妙に負けそうだが
739:名無しさん＠お腹いっぱい。
09/12/25 19:29:42 0nxqEmE70
それだけビットレートが違って負けてたら、そのmp3エンコーダーはおかしいだろ
740:名無しさん＠お腹いっぱい。
09/12/25 22:38:02 x+ht5gwV0
そもそもAACはmp3の欠点だった
低ビットレートの音質を改善したものだから
128kbpsだったらAACの方が音質がいいのは
当然だろ。
741:名無しさん＠お腹いっぱい。
09/12/25 22:43:14 eKfP0voF0
仕様として勝っていてもエンコーダの実装次第なので、当然ではない。
FAACとかは普通にLAMEに負ける。
742:名無しさん＠お腹いっぱい。
09/12/25 23:57:09 RlzzzXQF0
>>737
フリー版は旧製品版nero（昔の最新版）の型落ちだから
（あえて言うなら）旧製品版買った人全員、人柱だろ
まぁ、バグとかが無いとは言わないけどさ
743:名無しさん＠お腹いっぱい。
09/12/26 05:40:56 HR1JnEJf0
>>742
全く同じなの？
744:名無しさん＠お腹いっぱい。
09/12/26 08:33:40 dC79+0jwO
流れぶったぎるけど
地上デジタル放送のAACはエンコーダ何使ってんだろ？
ぐぐっても出てこないし。
745:名無しさん＠お腹いっぱい。
09/12/26 09:54:27 /enhg1urO
>>744
何って、ハードウェアエンコードだろ。
746:名無しさん＠お腹いっぱい。
09/12/26 19:07:21 QiQ9hlmv0
>>744
グリッドで云々じゃね?
747:a
09/12/27 08:48:50 0Wr1UhDT0
>>736
キタァァァァ
748:a
09/12/27 09:54:37 0Wr1UhDT0
foobar2000 & prelifeでエラー発生終了・・・
749:名無しさん＠お腹いっぱい。
09/12/27 10:20:24 A9xgwKa10
オレも foober やＧＵＩでエンコ失敗
エラーで再生できない
750:名無しさん＠お腹いっぱい。
09/12/27 12:30:31 07g48j+g0
foobarでエンコ出来た。
あと、ネロのデコーダにアウトプットファイルをパイプ?で指定したらバグったんだけど、
これってちゃんとデコード出来てるの？
751:名無しさん＠お腹いっぱい。
09/12/29 10:41:09 Nu2R4W230
>>748 >>749
URLﾘﾝｸ(www.hydrogenaudio.org)
752:名無しさん＠お腹いっぱい。
09/12/31 06:06:03 yvDDkymo0
AACに限らず音声圧縮についての質問なんだけど、
ビットレートがCBR192のソースに対して、最低ビットレートを192に設定してAACに圧縮した場合、
ビットレートは落ちてないしサイズも無意味に大きくなってるんだけど、音質は落ちたと考えて良いの？
753:名無しさん＠お腹いっぱい。
09/12/31 06:41:01 /RSCuOXQP
>>752
不可逆圧縮済みのソース->AACをすれば、二重に劣化する。
754:名無しさん＠お腹いっぱい。
10/01/01 01:25:31 wU791uzT0
1.5.3.0 (SSE bug fix)来てる
755:名無しさん＠お腹いっぱい。
10/01/01 14:37:46 4G++0cTY0
>>752 >>753
同様の質問が多く寄せられるって事は、
初心者の多くがつまづきやすいって事かな。
756:a
10/01/03 02:35:49 oCmigVU50
>>754
キタァァァァァ
757:名無しさん＠お腹いっぱい。
10/01/03 03:16:28 aAAdOY9I0
頭で考えずに自分の耳で確かめれば良い
そんなもん、つまづくに入るか
758:名無しさん＠お腹いっぱい。
10/01/03 10:21:41 D9wEpZIzP
1.5.3とかどこよ
759:名無しさん＠お腹いっぱい。
10/01/03 10:52:23 d0xcHjcH0
今1.5.1落とすと中のaacencだけ1.5.3に替わってた。
760:名無しさん＠お腹いっぱい。
10/01/03 11:06:25 D9wEpZIzP
>>759
なんだそれｗ
まじサンクス
761:名無しさん＠お腹いっぱい。
10/01/03 22:51:35 l2sHUPem0
itunesで128kbpsと320kbpsとで聞き比べたらより高音質のはずの320kbpsの方で
音量のバランスが悪いような感じの違和感があるのですがこれは気のせいでしょうか？
ちょっと古いバージョンのitunes使ってるせい？
762:名無しさん＠お腹いっぱい。
10/01/03 23:11:21 X7hLxKR70
サンプルも聞かずに誰がそんな質問に答えられるというのか
脳味噌腐ってるやつはいくら悩んだって無駄なんだから、気のせいってことにしとけ
763:名無しさん＠お腹いっぱい。
10/01/03 23:15:34 kVHH0Kss0
>>761
ソースのバランスが悪いんじゃないか？
ビットレート高い方が、当然ソースの粗もしっかり残してくれるぞ。
764:名無しさん＠お腹いっぱい。
10/01/03 23:26:44 l2sHUPem0
>>763
ソースはCDなんですけどね・・・
765:名無しさん＠お腹いっぱい。
10/01/04 00:33:23 B8yiMLN70
どういう返しやねん
766:名無しさん＠お腹いっぱい。
10/01/04 00:44:16 YdPN+QHt0
CDの音が狂ってるはずがないお＾＾； ってことだろ
767:名無しさん＠お腹いっぱい。
10/01/04 02:21:00 hJrijY7Q0
正月くらいCDも狂わせてやれよ
768:名無しさん＠お腹いっぱい。
10/01/06 01:07:56 CUVDH7Dd0
良かったら使ってくれ
URLﾘﾝｸ(tmkk.hp.infoseek.co.jp)
769:名無しさん＠お腹いっぱい。
10/01/06 06:35:12 6d94ht9FP
>>768
超絶GJ
770:名無しさん＠お腹いっぱい。
10/01/06 16:01:49 QgcfHCW80
1 out of 1 tracks converted with major problems.
Source: "D:\Harm.wav"
An error occurred while finalizing the encoding process (Could not start commandline encoder) : "D:\Harm.m4a"
Conversion failed: Could not start commandline encoder
コマンドラインからは正常にエンコできますが何故かfoobar2000だとはエラーが出る
Parameters:--abr 160 %s %d
QuickTime 7.6.5/XP SP3/foobar2000_0.9.6.9
771:名無しさん＠お腹いっぱい。
10/01/06 16:07:49 BAKTU94O0
>>768
超々絶GJ
マジでありがとう。動画用にQuickTimeでaacにしてるけどこれでいちいち
あの糞重いGUI起動しなくてすむし、コマンドライン処理で作業が大幅に
楽になる。すげ～嬉しい。
772:名無しさん＠お腹いっぱい。
10/01/06 16:18:02 BAKTU94O0
>>770
うちも同じ環境で今foobar試してみたけどプログレスバー一杯まで行って
temp-～.wavができたところでいつまでも作業が終わらない。
--tvbr 120 --highest %s %d
個人的にはコマンドラインからまともに動いてるから問題ないけど一応報告。
773:770
10/01/06 16:45:04 QgcfHCW80
foobar2000.cfg初期化したらいけるようになったけど何が問題なんだろう
foobar2000.cfg元に戻して
Preferences-Advanced-Tools-Converter
の設定値デフォルトにしても駄目だ
774:768
10/01/06 18:32:55 CUVDH7Dd0
>>770
hydrogenaudioでも似たような問題を報告してる人がいて、原因は良く分からん。
多分関係ないと思うけど--quietオプションでコンソール出力を止められるようにしてみた。
URLﾘﾝｸ(tmkk.hp.infoseek.co.jp)
>>772
プログレスバーが伸び切ってから時間がかかるのは仕様。パイプで渡せないので、
(1つのファイルの場合)バーが伸び切ってから実際のエンコードが始まる。
バーが伸びるまではfoobar側でデコード処理のみをやってる。
775:770
10/01/06 19:00:17 QgcfHCW80
>>774
既存のプリセットを選択してAdd Newではなく新規に追加したら一応エンコできるようになりました
でもちょっといじってると駄目になる場合も
776:名無しさん＠お腹いっぱい。
10/01/06 20:12:01 BAKTU94O0
> プログレスバーが伸び切ってから時間がかかるのは仕様
すいません、結構待ってみたんですがよく考えたらサンプルに使った
wavが結構時間の長い奴だった。それで途中で止めちゃったんですが
もう一度やってしばらく待ってみたら普通にエンコできました。
777:名無しさん＠お腹いっぱい。
10/01/06 20:31:58 ioCQF6ng0
>>768
QT SDK for Windows 7.0.3落としてVS2008でビルドしてみますた
IDEデバッグ実行すると途中でクラッシュします
具体的には600行目でnewしてるとこでstd::badalloc送出
よくわかりませんが590行目で確保してるバッファを多少増やすと
クラッシュしなくなりましたが、
QTのNewMovieFromDataRef()がエラー-2000を返してくるようです
コマンドプロンプトから単独実行すると動作するんですが
コマンドプロンプトでも何回か動かなかったときがありました
NewMovieFromDataRef()失敗時のエラーメッセージが出ていたので
同じ原因かと思います
iTunesについてくるQT7.6.5を使っています
778:名無しさん＠お腹いっぱい。
10/01/06 20:33:53 ioCQF6ng0
ちなみにデバッガで追う限り、ファイル名はまともに取れています
ファイルが無いからNewMovieFromDataRef()がエラーになっているわけでは
ないはず
779:768
10/01/06 21:35:59 Y8e/k9zr0
>>777
_tcscpy_sのサイズ指定を間違えてました。バイト数ではなく文字数。そりゃそうだ。
ただしこれはdebugビルドのみで起こる問題で、releaseビルドでは起こらない。
releaseだと文字列の終端で書き込みを止めるけど、
debugだと指定されたサイズの領域の最後まで問答無用で書き込むんだそうで。
ファイルが無い時にNewMovieFromDataRefでエラーになるのは仕様。
>コマンドプロンプトでも何回か動かなかったときがありました
は別の問題かと。
780:名無しさん＠お腹いっぱい。
10/01/06 21:48:38 ioCQF6ng0
>>779
NewMovieFromDataRef()の件ですが、相対パスの誤りだったようです
失礼しました
781:名無しさん＠お腹いっぱい。
10/01/06 23:17:12 kMLyyf7Z0
>>768のソフトでiTunes Plus設定にしたいなら
【--cvbr 256 --highest %s %d】で良いのかな？
たしかConstrained VBR 256kbpsの最高品質ってのだったはずなんだけど・・・
NeroAAC 1.5.3.0も出てるし、LAME3.98.2 V0で落ち着いていたのに
また非可逆設定の迷い道に入り込みそうだ。
782:名無しさん＠お腹いっぱい。
10/01/06 23:45:34 lMLb5vQh0
aac は -q 0.50 -ignorelength -if - -of %d
mp3 は -V 2 -q 0 --noreplaygain --strictly-enforce-ISO -S - %d
tak は -e -p2 -md5 -v -ihs -silent - %d
がいいよ
783:名無しさん＠お腹いっぱい。
10/01/07 02:20:26 gObcW7jN0
公開するにはまだまだの品質ですな。出直した方がいい。
784:名無しさん＠お腹いっぱい。
10/01/07 11:41:41 Z/oMTsu80
>>768
HE-AACを作れるコマンドはないのでしょうか?
785:名無しさん＠お腹いっぱい。
10/01/07 12:41:45 xxFj9Aa60
エンコード終わってもアウトプットされないんだが
786:名無しさん＠お腹いっぱい。
10/01/07 13:59:41 xxFj9Aa60
ConvertMovieToDataRef error: cannot convert the input file
787:名無しさん＠お腹いっぱい。
10/01/07 16:08:57 DjhC5Wvs0
mencoderだとQuickTime経由でのデコードはある(mplayer/libmpcodecs/ad_qtaudio.c ※)けど、QuickTime経由でのエンコードは無いんだよなぁ。
※ windowsのdllを利用してx86上のwindows/linuxで動く、macでは知らん
788:名無しさん＠お腹いっぱい。
10/01/09 16:31:27 aJ/fNyJT0
>>785
>>205らしい 自分も検索してここにたどり着いたけど無事解決
789:名無しさん＠お腹いっぱい。
10/01/12 20:20:48 JrSfoNzZ0
5.1ch音源をAACにする時、ターゲットビットレートどれぐらいで変換してますか？
790:名無しさん＠お腹いっぱい。
10/01/14 04:27:51 Vx/4niKR0
YAMB
791:名無しさん＠お腹いっぱい。
10/01/14 22:15:09 IJHWiWql0
320K
792:名無しさん＠お腹いっぱい。
10/01/15 20:21:50 +8VC0Tdg0
>>768
URLﾘﾝｸ(www.hydrogenaudio.org)
合法なの？
793:768
10/01/15 20:49:19 bqx3RHgu0
>>792
???
listening testでQT AACのtrue VBRを候補にする事に反対だという意見だが。
違法合法なんて話はどこから湧いてきたんだ?
794:792
10/01/15 21:34:55 +8VC0Tdg0
WindowsでTrue VBRのエンコードを行うには
QuickTime Proを買わなければならないってことはない？
その投稿の「EDIT」のところと、
URLﾘﾝｸ(ja.wikipedia.org)
>無料配布であってもライセンス料が発生する特許技術(AACなど)に関しては、Proからでないと利用できない。
って書いてあるのを見てふと疑問に思ったので。
間違った話してたらごめんなさい。
795:768
10/01/15 21:52:43 bqx3RHgu0
>>794
>EDIT: Does TVBR require QuickTime Pro? This would be another reason why I'd be opposed to TVBR.
は
True VBRでエンコードするにはQT Proが要るの? だとしたらそれも反対の理由になるな。
と言ってるだけ。つーかTrue VBRに限らずQT Playerから全てのフォーマットの書き出しを行うには
Proが必要。Macでも。
796:名無しさん＠お腹いっぱい。
10/01/15 22:26:21 4mDUQmmC0
>>768
truevbrの設定値とビットレートってどんな関係なの？
797:768
10/01/15 23:40:33 zwoVG4fF0
>>796
URLﾘﾝｸ(www.hydrogenaudio.org)
参照
>>794
補足しておくと、QT Proでしか使えない機能でも、外部のQTを利用したプログラムを使えば
自由に使う事が出来るし、そういうプログラムの作り方自体もAppleが公開している。
URLﾘﾝｸ(developer.apple.com)
Windowsで言うと、有名なところで携帯動画変換君もqtaacencと同じ仕組みで動いてる。
798:792
10/01/16 00:11:36 6kGXRy3j0
>>797
なるほど！ありがとう。
変な話をしてすまなかった。
greynolはqtaacencを前提にして書いているので、
何かライセンス等の問題はないのかなと思ったんだ。
799:768
10/01/16 00:52:14 TlFUXwcs0
いや別に前提にしてないと思うけど...
彼の発言は、
True VBRを候補に入れるのは反対。理由は他の人と同じ (iTunesでエンコードできないから)。
別に悪く言う訳じゃないけど、qtaacencについてはもう少し様子を見た方が良くないか?
という感じのニュアンス。
その下のeditは別にqtaacencの事を言ってるのではない。
おそらくPro状態でないQuickTimeでAAC書き出しが出来ると思ってたのだろう。
800:名無しさん＠お腹いっぱい。
10/01/16 01:30:03 fWlZ5MH60
>>797
どもども
やっぱ踊り場があったのか
801:名無しさん＠お腹いっぱい。
10/01/17 20:25:25 yr5+U3SH0
掲示板のグラフみたけど
外国の俺たちもQTのバージョンアップ及びエンコーダの改良で
クオリティ指定エンコでバージョンごとにビットレートが変わるのが嫌なんだろうよ
そのためにエンコーダツールを記録するタグがあるわけどさ
まぁクオリティ指定だからビットレートは変われど品質は変わらないのだけれど、
エンコーダの改良でなぜビットレートが上がっているのか不思議
おそらく大規模な改訂があったのだろうね
同様にビットレート指定エンコードもバージョンアップでいろいろ変わってると思うけど
802:名無しさん＠お腹いっぱい。
10/01/17 23:34:16 MD9K0XxA0
>>801
LeopardからSnow Leopardになった辺りで、
出来上がりのビットレートが変わった。
それを調べたグラフがHAにあって、このスレにもあったはず。
803:名無しさん＠お腹いっぱい。
10/01/17 23:54:30 yp/NMYVa0
>>801
別にVBRの品質指定は絶対的な品質に対応している訳ではないので、
バージョン毎に出来上がりのビットレートが変わる事は何もおかしくない。
804:名無しさん＠お腹いっぱい。
10/01/18 01:11:12 mxKo53PK0
>クオリティ指定エンコでバージョンごとにビットレートが変わるのが嫌なんだろうよ
なんで？何がいやなの？
805:名無しさん＠お腹いっぱい。
10/01/18 05:05:17 Ej5dgwJn0
VBRの品質指定が無意味になるから
806:名無しさん＠お腹いっぱい。
10/01/18 11:08:32 V8zTItq80
BDから抽出したDolby true HD 5.1chの音声があって、それをAACに1Mbps程度でエンコードしたんだけど、
オーディオ環境にいくらぐらいかけたら違いがわかるかな？
音量は夜の鉄筋マンションで聞ける程度で、あまり大きな音が出せない感じ。
807:名無しさん＠お腹いっぱい。
10/01/18 11:43:13 ZntMgHfI0
>>806
【8～256kbps】 AAC 音質ブラインドテスト 『雪、無音、窓辺にて。』‐ニコニコ動画(9)
URLﾘﾝｸ(www.nicovideo.jp)
808:名無しさん＠お腹いっぱい。
10/01/18 14:32:46 mxKo53PK0
>>805
>>803
809:名無しさん＠お腹いっぱい。
10/01/18 14:56:31 vIQN5bsM0
別にVBRの品質指定は絶対的な品質に対応している訳ではない(ｷﾘｯ
810:名無しさん＠お腹いっぱい。
10/01/18 14:57:37 wmUNJdRr0
そういや24bit/96kHzソースが
品質指定でどの程度のサイズに圧縮されるか
データとろうと思ってやってねぇや。
811:名無しさん＠お腹いっぱい。
10/01/18 15:03:39 9z7yQ/4LP
>>810
それ興味ある
応援してる（はぁと
812:名無しさん＠お腹いっぱい。
10/01/21 19:03:01 8KGJpUIt0
>>768
ギャップレスとツール名ｶｷｺGJ！
813:名無しさん＠お腹いっぱい。
10/01/21 22:00:07 txotKm5S0
pipeﾏﾀﾞｧ-? （･∀･ ）っ/凵⌒☆ﾁﾝﾁﾝ
814:名無しさん＠お腹いっぱい。
10/01/22 21:27:11 1FFbuKU10
ｷﾀ━(ﾟ∀ﾟ)━!!!!! おおきにGJ!!
815:名無しさん＠お腹いっぱい。
10/01/22 22:45:20 G8xColad0
pipe対応ｷﾀ Y⌒Y⌒Y⌒Y⌒Y⌒Y⌒(｡A｡)!!!
816:名無しさん＠お腹いっぱい。
10/01/22 23:02:39 vG8BXAO30
pipeに対応するとどういういいことがあるんですか？
817:名無しさん＠お腹いっぱい。
10/01/23 03:29:45 dhfEeoAC0
| ←これで処理できる
818:名無しさん＠お腹いっぱい。
10/01/24 00:07:32 gp3YC5yR0
>>816
ファイルに書き出さずに処理できるから速くなる
819:名無しさん＠お腹いっぱい。
10/01/24 00:30:01 KAHxU5YH0
>>768
version 20100122
--cvbr 192 --highest --samplerate keep or 48000
で48000のが44100ではき出されちゃいます。
--samplerateオプション削ると48000のままでOK。
820:768
10/01/24 04:41:14 1EFdf+K/0
>>819
最初のバージョンを出す前に直したバグだと思ってたら
いつの間にかソースコードが元に戻ってたでござるの巻
821:名無しさん＠お腹いっぱい。
10/01/24 07:54:40 zSdRn9yW0
乙！
822:名無しさん＠お腹いっぱい。
10/01/24 23:32:00 Uezao6YF0
>>820
ついでにフロンドエンドというかGUI版もつくってほしい
日本語解説も
823:768
10/01/24 23:53:08 1EFdf+K/0
>フロントエンド
WindowsユーザじゃないからAPIや流儀をいちいち調べるのが面倒でつくりません
というかfoobarその他じゃ駄目なの?
>日本語解説
この規模のソフトで要るか?
824:名無しさん＠お腹いっぱい。
10/01/24 23:54:32 Uezao6YF0
oh sorry...
825:名無しさん＠お腹いっぱい。
10/01/25 04:38:41 fySE21y90
ていうかGUI欲しかったらQuickTimePlayer使えば良いんじゃね？
826:名無しさん＠お腹いっぱい。
10/01/25 07:36:13 Tz8Ij5dV0
>>768
蒼弓さんやきたへいさんと比べると英語が堪能な気がするんだけど、
どうやって勉強したのん？
受験英語やHAの読み書き以外に何かした？
827:名無しさん＠お腹いっぱい。
10/01/25 10:51:58 JRRGe9d10
>>822
位置づけとしてはlame.exeやneroAACenc.exe、flac.exe、oggenc.exeなどと
同等のプログラムなので、GUIを期待するのは間違いでしょう
>>823
＞Windowsユーザじゃない
あー薄々そんな気はしてたけどやっぱりか、それは凄い
MacのBoot Campか何かの仮想環境でVS2008使ってるということですか？
今更だと思いますが、開発がMacなら、gccでクロスコンパイル
するほうが楽だったかもしれませんね
828:名無しさん＠お腹いっぱい。
10/01/25 13:08:16 z+tp8TZ50
ライセンスも英語か
ソース同梱されてるけど再頒布とか改変とかOK?
829:名無しさん＠お腹いっぱい。
10/01/25 18:57:28 javpe0n20
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
AACはモバイル系放送でテレビ・ラジオともにデファクトスタンダードになる。
830:名無しさん＠お腹いっぱい。
10/01/25 19:32:38 CsYmeiSY0
映像圧縮はどんどん進化してるのに、AACの次は出ないのかよ
256kbpsでロスレスで頼む
831:名無しさん＠お腹いっぱい。
10/01/25 19:42:46 J4si0T+s0
>>830
電子ピアノで簡単な曲ならロスレス圧縮すれば250kbpsくらいにはなるぞ
832:名無しさん＠お腹いっぱい。
10/01/25 19:44:24 FwIAv6XZ0
BGMのない語学系ならもっと縮むな
833:768
10/01/25 23:59:53 lFsy0dZi0
>>826
それなりに英語を使う立場に居るので。
まあ外国語は勉強だけしてもあまり使えるようにならんですよ。
>>827
日常的に使ってないだけで、Windows機自体は持ってます。
クロスコンパイルは考えた事がなかったけど、開発環境自体に不満はないので。
>>828
MITライセンスを参照
834:名無しさん＠お腹いっぱい。
10/02/03 17:48:18 dJpm9sN40
俺ダメな子だからxrecode IIを愛用している
835:名無しさん＠お腹いっぱい。
10/02/07 00:39:24 iRFoxpdD0
Nero AAC 1.3.3.0 でエンコードしたファイルを iTunes にインポートすると
gapless なのは gapless で再生されるようですがこれって iTunes が Nero の
gapless 情報(tag or header)を、iTunes が LAME tag に対応してるのと同様に
対応してるってこと?
836:名無しさん＠お腹いっぱい。
10/02/07 02:28:04 Ja4Io/gX0
>>835
余談から始める
（AACしか知らないが）まずiTunesでCDをエンコードするとどんなやつでも（新しいiTunesとiPodで）連続再生したとき
ギャップレス（わかりやすいライブ音源で言うと空白なし）でエンコードされている。（1）
プロパティのオプションのギャップレスのチェック欄は、このCDがギャップレスだからクロスフェード再生がオンのときクロスフェードさせるなっていう目印なだけ。
紛らわしいよね、このチェック欄の名称。（例えば、”クロスフェード時にクロスフェードさせない”とかが相応しいかと思う）
詳しいことは以下に書いてある
URLﾘﾝｸ(support.apple.com)
だから結論としてはNeroがiTunesのエンコードの仕方（1）にあわせてるんじゃないか？tagとかheaderとかじゃなく。
上のqtaacenc.exeも（1）のエンコードの仕方に準拠してるしね。
837:768
10/02/07 02:47:04 k0GugzYW0
>>836
エンコード自体をギャップレスで行うことは不可能。
MDCTを行う性質上、総サンプル数を1024の倍数にするために
先頭や末尾に余分なサンプルが追加されてしまう。
そのため、qtaacencもiTunesもエンコード時にギャップレス再生のための情報を
タグとして付加している。それがないとギャップレス再生は不可能。
NeroがiTunes準拠のギャップレス情報を付加するのは最新バージョン (1.5.1.0) から。
1.3.3.0でもギャップレスOKということは、iTunes側で対応してる可能性が高い。
838:名無しさん＠お腹いっぱい。
10/02/07 03:46:50 iRFoxpdD0
>>836-837
なるほど。やっぱそうなのか。HAのKBやフォーラム漁っても見つけられなかった
のでおかしいなと思ってたんだけど…
ちなみにそのiTunesと同期したiPod classic 80Gでもギャップレス再生できてます。
曲はPink FloydのDark Side of the Moonとかいろいろなライブ盤とか。
839:名無しさん＠お腹いっぱい。
10/02/07 04:12:07 iRFoxpdD0
wikipediaには一応書いてあった
URLﾘﾝｸ(en.wikipedia.org)
>AAC in MP4 encoded with Nero Digital from Nero AG can be gapless with foobar2000, latest XMMS2, and iTunes 7.1.1.5 onwards.
840:名無しさん＠お腹いっぱい。
10/02/07 09:40:31 09BM03cqP
768氏
URLﾘﾝｸ(tmkk.hp.infoseek.co.jp)
この記事はもう更新されない？
QuickTimeのバージョンかなり上がってるけど今も同じと考えていいのかな？
841:名無しさん＠お腹いっぱい。
10/02/07 13:10:52 oulAfCo00
QuickTimeは7.6かなにかで大幅にAACエンコーダが変更になったらしい。
842:768
10/02/07 13:33:03 k0GugzYW0
>>840
QT7.6で変わった。さらに細かく言うとQT7.6.2でも変わった。
ビットレート変動の傾向について言えば、constrained VBRの
ビットレート平均化の挙動が大きく変わって、true VBRと似た感じになった。
URLﾘﾝｸ(tmkk.hp.infoseek.co.jp)
843:名無しさん＠お腹いっぱい。
10/02/07 14:29:17 09BM03cqP
>>842
おお！ありがとう！
もう一つだけ聞きたいんだけど、qtaacencはHE-AAC対応予定はありますか？
844:768
10/02/07 14:46:30 k0GugzYW0
>>843
HE-AACに対応できないのはQuickTime自体の問題なので、
qtaacenc側ではどうしようもない。
845:名無しさん＠お腹いっぱい。
10/02/07 14:57:35 09BM03cqP
>>844
あれ…
iTunesではHE-AACエンコに対応してたのでてっきりできるかと思ってました
すみません
846:768
10/02/07 15:26:12 k0GugzYW0
iTunes自体がエンコーダを持ってるのか隠しAPIがあるのかは知らんけど
WindowsのQTではHE-AACエンコーダにアクセス不可能。
847:名無しさん＠お腹いっぱい。
10/02/07 16:07:59 09BM03cqP
>>846
非常にご丁寧な対応ありがとうございます
qtaacenc非常に助かっております
これからも応援してます
848:名無しさん＠お腹いっぱい。
10/02/07 22:47:23 Psl6j4ts0
時間あったらAACBitrateGrapherのWindows版ください
MP3BitrateGrapherは解説どおり4.4.1-tdm-2でコンパイル
849:名無しさん＠お腹いっぱい。
10/02/09 08:07:34 JTOx1HN90
qtaacencでcvbrでエンコするとMediaInfoで確認するとCBRになっちゃうね
850:768
10/02/09 13:21:15 aU0WlyEv0
>>849
mediainfoの挙動はMPEG-4 AACのBit rate modeに関して言えば
esds atomの平均ビットレート、最大ビットレートの値を見て
平均ビットレートより最大ビットレートが大きいとVariableと表示するだけ。
QuickTimeはこれらのフィールドに正確な値を書き込まないのでそうなる。
平均ビットレートに関してはqtaacencの内部で計算して上書きしてるけど。
mediainfoは「ファイルが主張する値」と「実際の値」を混ぜて表示するので
表示されたものをそのまま盲信するのはよろしくない。
最大ビットレートに関しても内部で計算できないことはないので、
気になるようだったら直すけど。
851:名無しさん＠お腹いっぱい。
10/02/09 14:03:35 18DVruDj0
>>850
勉強になる
再生で問題がないなら別に直さなくてもいい気がする
どうするかはお任せします
852:名無しさん＠お腹いっぱい。
10/02/10 01:22:02 PmWh15Iu0
>>768
更新してるねthx
853:名無しさん＠お腹いっぱい。
10/02/10 04:41:47 sDp9JcLL0
クイックタイムって2ch超えるwav対応してないよね？2ch以下じゃ4GB超えるような事
滅多にないだろうけど乙。
854:768
10/02/10 04:53:34 cHlKUhBv0
2ch超を扱えないのはQTではなくqtaacenc側で意図的にやってる制限。
制限はそのうち解除する。
855:名無しさん＠お腹いっぱい。
10/02/10 07:13:02 5HoyiBKG0
neroAacEncにも--ignorelengthってあるけどこれって4GB以下の時にも指定しても特に問題って起きないの？
バッチ作るときに容量で分岐させてきちんと4GB未満のときだけ指定するようにしたほうがいいのかな
856:名無しさん＠お腹いっぱい。
10/02/10 16:42:42 qcEEDwc40
>>855
dataチャンクの後に何か入ってるようなWAVなら、その部分がゴミになるわな
857:名無しさん＠お腹いっぱい。
10/02/10 16:51:42 qcEEDwc40
>>856で言ったのは別のチャンクが入ってるWAVの場合だけど
それとは別のケースとして
たとえばa52decでAC3をデコードしてWAV出力させた場合、正確なdataチャンク長は
デコードしてみないと分からないので、最初は0xffffffffにしておいて、
後でシークして書き換えるようなことをやっているようだ
そういうのをパイプで食わせると、他のチャンクは無いんだが
ケツにdataチャンク長を示す4バイトのゴミが来ると思う
この手のはRAW PCMで流せたほうが安全は安全だわな
858:855
10/02/11 15:52:35 UiAMwt1U0
解説ありがとー
859:名無しさん＠お腹いっぱい。
10/02/11 17:21:09 H8Q+06j+0
qtaacdec.exeは仕様的には作成できるの？別にNeroDecでいいんだけれど聞いてみた
860:768
10/02/11 17:30:22 j1eGNdWs0
>>859
可能 つくる予定はないけど
861:名無しさん＠お腹いっぱい。
10/02/11 17:50:48 H8Q+06j+0
おー即レスどうもです。結構オープンなんですね。
862:名無しさん＠お腹いっぱい。
10/02/11 17:51:10 5NlY0ZWCP
もったいぶるなカス
863:名無しさん＠お腹いっぱい。
10/02/11 18:06:36 ofNSbfuNP
>>862
よおクズ
864:名無しさん＠お腹いっぱい。
10/02/11 21:55:39 Aa4dw5UY0
AAC内部のこと聞いていいかな？
AACを無劣化で分割したくて今ADTSヘッダについて調べてる。
手元にあるm4aファイルをバイナリエディタで見て、FF Fxで始まる部分を
ヘッダの開始位置とみなし、仕様と照らし合わせてみたんだけど、
なぜかフレーム毎にヘッダの情報が大きく異なってしまってる。
サンプリングレートやチャンネル数、LCとかMainを決めるProfileからしてバラバラで、
再生ソフトはどこを見て正しい情報を得てるのかなっていう。
フレームごとにヘッダ情報がバラバラなのは普通かな？
865:名無しさん＠お腹いっぱい。
10/02/11 22:01:29 sxW9Cyy80
>>864
tmkk氏じゃないが
MP4コンテナの中のAACは生のままで入ってるから、ADTSヘッダはついてないよ
ADTSヘッダに近い情報はesdsアトムのdecConfigDecrってとこに入ってる
mp4v2ってライブラリのオマケのmp4fileってコマンドで解析すると良いよ
866:名無しさん＠お腹いっぱい。
10/02/11 22:03:09 sxW9Cyy80
×decConfigDecr
○decConfigDescr
だごめん
867:名無しさん＠お腹いっぱい。
10/02/11 22:07:51 Aa4dw5UY0
>>865
うおお、そうだったのか！
やっぱ聞いてみるもんだな…ありがとう！
868:名無しさん＠お腹いっぱい。
10/02/12 11:19:30 oRifmxFA0
nao氏に質問。水素掲示板でqtaacencのスレだけ凄い盛り上がってるけど外国の人達は今なについて語ってるの？
869:名無しさん＠お腹いっぱい。
10/02/12 23:00:01 DQgdFgib0
nao氏じゃないが、自分の環境で試したこととか試した結果おかしいと
思ったこととかの確認がほとんどだね。
870:768
10/02/12 23:01:54 7d2NbBm60
>>868
いや別に盛り上がってないと思うけど...ここ3日ぐらいは書き込み無いし。
少し前は勝手に働くゲイン調整の話とか。
871:名無しさん＠お腹いっぱい。
10/02/13 04:16:23 hwCJe95J0
リミッターが掛かってる、って話はなるほどと思った。
音量が小さく、ダイナミクスが少し狭い感じに聞こえるんだよね
低ビットレートだと >qt
872:名無しさん＠お腹いっぱい。
10/02/13 16:44:03 4DslZhpe0
鮫鮫鮫
873:名無しさん＠お腹いっぱい。
10/02/18 00:31:20 9Wc61s8x0
あとは--helpで配布ページみたいなオプションヘルプ表示できたら完璧
874:名無しさん＠お腹いっぱい。
10/02/18 01:20:40 Ya6dBCfP0
普通にでるだろ。まさかfoobarとかのExamplesまで載せろとか言ってんの？
875:名無しさん＠お腹いっぱい。
10/02/18 06:37:02 JCpfcqKp0
サイト見れば全部載ってるじゃねえか
大して需要もない要望ばっか言ってると開発やめちまうぞ
作者側の負担減らすようにしろよ
876:名無しさん＠お腹いっぱい。
10/02/18 08:53:55 9Wc61s8x0
ごめん。作者さんごめん
--helpもじっと待ってれば表示された。でも引数の解析中にエラー起こしてて表示まで引っ掛かりがある
それとHE対応ありがとう 感謝
877:名無しさん＠お腹いっぱい。
10/02/18 10:08:35 DyD77KxZP
こっそりHE対応してんじゃん
これで最強だな
878:名無しさん＠お腹いっぱい。
10/02/18 11:16:55 i4YXsayf0
一方ロシアはNeroを使った
879:768
10/02/18 11:46:23 fzxQw41w0
>>876
--helpなんてオプションは無い。
引数無しで起動するとusageを表示して終了する仕様
解析じゃなくてQTの初期化に時間がかかってるだけだと思うけど。
2回目以降は速いでしょ
880:名無しさん＠お腹いっぱい。
10/02/18 13:09:15 8bCyELBz0
>>876
www
881:名無しさん＠お腹いっぱい。
10/02/18 13:56:40 xPZm26Bc0
qtaacencすごいね
やっと出たかって感じ
ところでqtとneroはどっちが音いいの？
882:名無しさん＠お腹いっぱい。
10/02/18 14:00:56 V7h/YlHu0
耳がついてるなら自分で確かめてみればいいじゃない
883:名無しさん＠お腹いっぱい。
10/02/18 14:44:14 9Wc61s8x0
>>874
でてこいやこの野郎ｗ やっぱhelpなんてオプションないじゃないか
大抵のCLIツールって-h とか-helpでサクっとオプション一覧でるから合わせた方がいいと思う
qtaacencでHEエンコしたもので不思議なのはサンプリングレートが22050Hzではなく44100Hzと認識されているところ
iTunesでエンコすると22050Hz。なんか書き換え作業やってるのか？
ちなみにiTunesでもHEv2作れる。特定の条件下だが
例えば1chで32kbps/2chとか。つまり16kbps/1chとかにするとv1じゃなくてv2でエンコされる（ただし32kHz）
不具合としてはiTunesで再生時間が倍に認識されるぐらいか。
HE-AACの特殊な圧縮法による問題だな。サンプリングレートが半分になったり、再生時間が倍になったり
作者頑張れ！人口増加のために街にアクセスしています
884:名無しさん＠お腹いっぱい。
10/02/18 14:46:33 XbxQfg3f0
>>883
皆がやってるからこうしたほうが良いはどうかと思うぞ
885:名無しさん＠お腹いっぱい。
10/02/18 15:09:23 DyD77KxZP
>>883
講釈垂れる前にqtaacenc.exe --help打ってみろ
886:名無しさん＠お腹いっぱい。
10/02/18 15:10:54 9Wc61s8x0
↑ワロス
887:名無しさん＠お腹いっぱい。
10/02/18 15:14:19 DyD77KxZP
うん？>>876と同じ奴じゃねーか
出るの知ってて文句言ってんのか
よっぽど叩かれたのが悔しかったのか
888:768
10/02/18 15:19:14 fzxQw41w0
>>883
-hや--helpを指定しなくても表示する仕様だと>>879で言ってるのだが、理解してもらえないのだろうか?
874の言ってる事は別に間違ってない。
サンプルレートの表示はtimescale絡みの問題で、これは基本的に再生ソフト側の問題。
とはいえiTunesと合わせておくのが無難なので、次のバージョンで直す。
iTunesで再生時間がおかしいのはギャップレス情報が間違っているせいで、
これも次のバージョンで直す。
HEv2ではエンコードできない。iTunes云々は低サンプルレートのLC-AACと同様
フラグが立ってるだけか誤認識。つーかQTはPSのデコードすら非対応。
889:名無しさん＠お腹いっぱい。
10/02/18 15:46:17 9Wc61s8x0
＞理解していないのだろうか？
理解してるよ
--helpなんてそもそも存在せずオプションなしでオプション一覧が表示されるんでしょ
それは>>879を読んで理解したよ
俺の考えは無指定で表示されるのもいいけど、初めて使う人向けに一般的な--helpでもQTの初期化せずサクっとラグなしで出して欲しいだけ
（まさか無指定で一覧表示されるとはおもってないだろうし）
作者が無指定で表示されるから変える必要ないと考えているようなのでこのままでいいよ
考え方は人それぞれだし、自分の考えを無理やり押し通すわけにもいかないし。
別に喧嘩したいわけでもないし、ありがたく利用させて頂いてる身だし、作者には感謝してるよ
まぁこの件はこれでおしまい
サンプリングレートがHEなのに22ではなく44になってる件だけどmp3infpとか真空波動研とかで見た時の話ね
iTunesのプロパティでは両方共44で無問題。直すところはないと思われる
再生時間が倍になる不具合は修正頼む 開発頑張れ！
890:名無しさん＠お腹いっぱい。
10/02/18 15:58:36 JCpfcqKp0
イッパンテキ（笑）
俺はどんなものでも--helpなんて使わずに無指定で試すわ
-hの場合もあれば--helpの場合もあれば-helpの場合だってあるじゃん
無指定でやると大抵「ヘルプはこうやれ」って指示が出てくる
891:名無しさん＠お腹いっぱい。
10/02/18 16:08:36 DyD77KxZP
理解してないだろｗ
--helpつけようがつけまいが同じ処理してるって
どっちも2秒くらいで出る 2秒も待てないとかそんなのはワガママだ
892:768
10/02/18 16:16:59 fzxQw41w0
んじゃ引数無しで起動した場合は初期化せずにusageを表示するようにしとくよ
個人的には890と同意見なので--helpとかは作る予定無し
>直すところはないと思われる
foobar絡みの問題だが、ギャップレス情報の問題を直すために同時に直さないと駄目。
893:名無しさん＠お腹いっぱい。
10/02/18 16:22:26 9Wc61s8x0
初期化せずラグなしならそれでいいよ
890みて自分の持ってるやつ試したらほとんどそうで考え変わったし
これでこの件は本当におしまいな
894:名無しさん＠お腹いっぱい。
10/02/18 16:29:23 HGFKVbfU0
上から目線ﾜﾛﾀ
895:名無しさん＠お腹いっぱい。
10/02/18 16:40:42 8bCyELBz0
ID:9Wc61s8x0
↑何時間このスレに張り付いてんだよ。きもすぎ。
896:名無しさん＠お腹いっぱい。
10/02/18 18:41:06 RUqEOrf80
※お察しください
897:768
10/02/18 18:44:40 fzxQw41w0
何故mediainfoがSBR/PSを誤爆するのか調べてみたら
こんな投げやりなコードが
if (!Is3GP) //If this is not a 3GP file
{
if (!sbrPresentFlag && samplingFrequency<=24000)
{
samplingFrequency*=2;
sbrPresentFlag=true;
}
if (!psPresentFlag && channelConfiguration<=1) //1 channel
psPresentFlag=true;
}
implicit signalingってこういう判断しちゃ駄目だと思うんだけど...
898:名無しさん＠お腹いっぱい。
10/02/18 19:58:33 L+y7J3hgP
高音がないCDをTVBRで圧縮すると物凄く縮む 素晴らしいねAAC
899:名無しさん＠お腹いっぱい。
10/02/18 23:21:18 V5alxrpl0
>>897
flagをtrueにする判断がおかしすぎてワラタ
900:名無しさん＠お腹いっぱい。
10/02/19 01:46:51 kQ81/hnO0
MediaInfoは便利に利用してるんだけど、確かになんか怪しい部分はあるなー
例えばWAVEFORMATEXTENSIBLEなWAVのGUIDも非標準的なバイトオーダーで印字してるし
まああれは参照だけだから、壊れたファイル作るとかよりずっと害は少ないけど
URLﾘﾝｸ(mksoft.hp.infoseek.co.jp)
こういうの見るとなんか涙ぐましいものを感じる
901:名無しさん＠お腹いっぱい。
10/02/19 11:47:01 AMrE0MBeP
少なくとも20100124でエンコードしたものは本来のものと再生時間がすべて千分の数秒違う
最新版では問題が解消されているのを確認したので最新版でのエンコードをオススメする
激しく768氏乙
902:名無しさん＠お腹いっぱい。
10/02/19 13:53:03 AMrE0MBeP
901はなかったことにしてくれ、20100124でもまったく問題ない
千分の数秒狂うのは自分のせいだったようだ（SMPBがこんなに大事とは・・・）
903:名無しさん＠お腹いっぱい。
10/02/19 14:02:32 kQ81/hnO0
HE対応が凄いが、いつの間にか地味に多チャンネルも対応してたんすね
windbgか何かでiTunesの動作を追跡したんですか？＞作者
>>901
20100124版は使ってないし見てもいねーので完全に想像で書き込むけど
ソースからの音声抽出に最近のバージョンで使うようになった（ように見える）
QuickTimeのMovieAudioExtraction APIのせいじゃないかなあ
あれデフォルトだと本来のサンプル数より若干短めになるみたいなんだわ
一種のQuickTimeのバグだと思うんだけど……
少なくとも現在のqtaacencのコードだと、タイムスケールをトラックの出し入れで
強制的に再認識させてるみたい
904:903
10/02/19 14:05:16 kQ81/hnO0
リロードしてなかったよｗ
狂いはなかったんなら良かったね
905:名無しさん＠お腹いっぱい。
10/02/19 14:29:16 AMrE0MBeP
＞MDCTを行う性質上、総サンプル数を1024の倍数にするために
＞先頭や末尾に余分なサンプルが追加されてしまう。
＞そのため、qtaacencもiTunesもエンコード時にギャップレス再生のための情報を
＞タグとして付加している。それがないとギャップレス再生は不可能。
このタグがITUNSMPBなんですね、非常に勉強になりました
906:768
10/02/19 15:01:43 2h3Y+u5v0
>>903
HE-AACに関してはMac版のiTunesの挙動をgdbで追っかけました。
数ヶ月前にも一度疑問に思ってやったんだけど、当時はエンコード開始時の
挙動しか追っかけなくて結局分からず。今回は起動時の挙動を追っかけて
方法が判明しました。
907:名無しさん＠お腹いっぱい。
10/02/19 15:21:34 kQ81/hnO0
>>906
レスどうもです
やっぱりそういう方法でしたかｗ
908:名無しさん＠お腹いっぱい。
10/02/19 22:10:05 aL2qri0g0
768さん、マジ乙。
909:名無しさん＠お腹いっぱい。
10/02/19 23:06:29 HIuHTW7T0
なぜデフォが65なのか謎は深まるばかり
910:768
10/02/19 23:24:03 7hyQWFMP0
128kbps前後になる設定ということで、特に深い理由がある訳ではない。
911:名無しさん＠お腹いっぱい。
10/02/19 23:28:27 UFA55oVI0
なるほどね
0-127の中央値だからかと思ってた
912:名無しさん＠お腹いっぱい。
10/02/20 01:20:51 VovZlP3S0
じゃあ俺は半分の64にしよう
913:名無しさん＠お腹いっぱい。
10/02/20 03:09:42 8pg+iQ6h0
qtaacenc密かに多チャンネル対応って上にあったからワクワクしてエンコしたんだが
ダウンミックスされちゃうのか… これって5.1chのaacで吐き出すのは無理ですか？
914:768
10/02/20 03:26:41 Rtn/FQom0
無理じゃないけど。入力フォーマットは何?
915:名無しさん＠お腹いっぱい。
10/02/20 04:16:22 8pg+iQ6h0
>>913
WAV（pcm5.1ch）ってこういう答えで良いんですかね。チャンネルオーダー
直すのも自動でやってくれれば嬉しいですがなんなら手動で入力するものの
チャンネルオーダー変えるとかでも問題ないです。
916:768
10/02/20 04:47:39 Rtn/FQom0
QTはチャンネルオーダが不明の場合は勝手に1chにダウンミックスするようなので
とりあえずwavの場合はパイプでやってみて。
この場合入力にQTを通さないのでうまくいくはず。
917:名無しさん＠お腹いっぱい。
10/02/20 05:52:25 8pg+iQ6h0
>>916
ありがとうございます。
avsで音声読み込み
"avs2wav" "%~1" - | "qtaacenc.exe" --cvbr 128 --highest --samplerate keep "-" "%~1.m4a"
Soundout(output="cmd", filename="hoge.m4a", autoclose=true, executable="E:\hoge\qtaacenc.exe", prefilename="--cvbr 128 --highest --samplerate keep -")
とりあえずこの2つで試して見ましたがばっちりです。チャンネルオーダーも自動でOKでした。
918:名無しさん＠お腹いっぱい。
10/02/20 13:39:37 3T8YStjl0
>>917
今見たけど、avisynthってWAVEFORMATEXTENSIBLEな5.1chWAVをWAVSource()で
読ませても、何食わぬ顔をしてWAVE_FORMAT_PCMで出力するんだね
もちろんチャンネルマスク情報は消え去ってしまう
どうで使うのは5.1か7.1の標準的なMPEGオーダーだから誰も困っていないのか
音声トラックをdemuxしてfoobarに任せたほうがいいんじゃねえのかなあ？
919:768
10/02/20 13:58:40 Rtn/FQom0
>>918
7.1に関してはちょっと問題で、L R C LFE Ls Rs Lc Rcと
L R C LFE Ls Rs Rls Rrsの2種類が主に使われてるっぽい。
前者は5.1+フロント2ch、後者は5.1+サラウンド2chなのだが、
どちらが一般的なのだろうか。QT AACは7.1chというと前者を想定する。
wavのチャンネルマスク的には、先頭から全部詰め込まれているとすると前者か。
920:名無しさん＠お腹いっぱい。
10/02/20 14:28:02 3T8YStjl0
>>919
前者はCoreAudioのkAudioChannelLayoutTag_MPEG_7_1_Aで、後者が～7_1_Cかな？
俺も前者でいいんじゃないかと思いますが、全く自信は無いですｗ
この辺の話題に関しては、HydrogenaudioよりDoom9のフォーラムのほうが
面白い意見を聞けるんじゃないでしょうか
921:名無しさん＠お腹いっぱい。
10/02/20 18:01:20 x2EcTWI70
ルーチンのなんたらかんたらでサイズがコンパクトになったねъ(ﾟДﾟ)ｸﾞｯｼﾞｮﾌﾞ!!
922:名無しさん＠お腹いっぱい。
10/02/20 18:05:34 2zeL3RXxP
あ、更新されてる
乙
923:名無しさん＠お腹いっぱい。
10/02/20 18:26:05 3T8YStjl0
あ、新しい版ではSCSetSettingsFromAtomContainer()使うのはやめたんですね
正直以前の版だと、あの辺はちょっとdirtyだと思ってました……
新版のほうがずっといいですね
924:名無しさん＠お腹いっぱい。
10/02/20 20:48:07 VovZlP3S0
foobar+qtaacencでエンコしてると
クリップボード補助ソフトが動かなくなる・・・
neroだとならないんだがなあ
925:768
10/02/21 02:19:33 5ks98vj60
>>917
パイプじゃなくてもOKになった...はず
926:名無しさん＠お腹いっぱい。
10/02/21 14:12:06 0duI0OHiP
Low Complexityプロファイル以外にもMainプロファイルのAACがあるようだけどみたことがない。
これってエンデコーダってあるの？知っている人いたら教えてください。
927:名無しさん＠お腹いっぱい。
10/02/21 23:52:59 ivBuazcM0
>>926
faac、faad
928:名無しさん＠お腹いっぱい。
10/02/21 23:56:33 0duI0OHiP
ありがとう ためしてみます
929:名無しさん＠お腹いっぱい。
10/02/22 04:03:31 1O6oARWZ0
768さんへ伝言
某IRCにて
(kierank) and vs2008 crashes because of japanese again...
(brbrbr) cause japanese code portions ?
(brbrbr) thats why cross-platform developing tools/framework/library so matter
(brbrbr) example Eclipse/GCC/QT
(kierank) japanese naming i think
(Chikuzen) (kierank) and vs2008 crashes because of japanese again... <---qtaacenc ?
(kierank) yes I was trying to open the source
(kierank) and it locked up the whole system
(kierank) Chikuzen, you could tell him he has broken line endings though
(Chikuzen) k, i will post this log.
930:768
10/02/22 04:38:59 4KzkcXV40
>>929
ソースコードの中に日本語は無いと思うけど、.vcprojと.rcの中にあった。
こんなんがクラッシュを引き起こすほどの悪さをするのだろうか?
Windowsはよくわからない...詳しければ教えてください。
ソースコードの最後の改行するようにします。ごめんなさい
931:名無しさん＠お腹いっぱい。
10/02/22 04:53:38 1O6oARWZ0
>>930
自分はコードを読めも書けもしないので分かりませんが、
kierank氏によれば、これはVS2008が悪いそうです
まあ、海外の人もユーザーの対象になる場合は、なるべく使わない方がいいんでしょうね
932:名無しさん＠お腹いっぱい。
10/02/22 04:55:41 1O6oARWZ0
あと、こんなことも言ってた
(brbrbr) so MS claims about NLS was [as always]BS ?
(brbrbr) same about Russian lang in OS and IDE's
(brbrbr) :/
(brbrbr) or at least NLS cause appx 15% speed penalty
933:名無しさん＠お腹いっぱい。
10/02/22 18:33:14 FmZXtYmt0
>>925
やっと規制解除された。ありがとうございます、前に駄目だったのを試して
OKでした。
934:名無しさん＠お腹いっぱい。
10/02/24 18:43:43 gr2DrUAT0
東京・大阪のAM/FM 13局が3月15日からサイマル配信
－「radiko.jp」。実用化試験で半年後目処に実用化
URLﾘﾝｸ(av.watch.impress.co.jp)
> Webページでの配信はFlashを用いたプレーヤーで行なわれ、
> 各局ともHE-AAC 48kbpsのステレオでストリーミング配信される。
935:名無しさん＠お腹いっぱい。
10/02/24 20:23:43 H/izpYQK0
>>934
IPアドレスで視聴地域を限定？
アホらし┐(ﾟ～ﾟ)┌
936:名無しさん＠お腹いっぱい。
10/02/24 23:52:09 3WmfT7uZ0
限定しないと地方局が死ぬんだろ
937:名無しさん＠お腹いっぱい。
10/02/25 00:53:01 qPFlCMjc0
いつまで護送船団方式に頼ってるんだよｗ
ラジオに限らずテレビもそんなんだから誰からも見向きされなくなったんだろ
競争に晒されない組織はいずれ飽きられて誰からも見向きもされなくなる
938:名無しさん＠お腹いっぱい。
10/02/25 00:57:42 Fv8F2oby0
半公共物になってるもんをおいそれと倒産させられるかよ
それで問題がないならとっくにTVもラジオも潰れるのはお前もよく分かるだろ
939:名無しさん＠お腹いっぱい。
10/02/25 01:03:32 qPFlCMjc0
潰れちゃいけない理由でもあるか？
940:名無しさん＠お腹いっぱい。
10/02/25 01:05:56 r1Tz3MyJP
他所でやれおまえら