【Opus/Vorbis/FLAC】Ogg統合20【AV1/Theora】
■ このスレッドは過去ログ倉庫に格納されています
http://www.xiph.org/ Xiph.Org Foundation(ザイフォ財団)により運営されている パテントフリー、オープンソースのマルチメディアプロジェクト コアライブラリには修正BSDライセンスを採用しており、 商用非商用関係なく、使用・配布など全てを自由に行えるのが特徴 【前スレ】 【Vorbis/FLAC】Ogg統合19【Theora/etc...】 http://egg.5ch.net/test/read.cgi/software/1393839807/ やっぱ地球はダメだよね、第3惑星程度じゃ太陽に近すぎてフレアのノイズが乗ってくる。 冥王星程度まで離れるとかなり静かな環境なんで、クラッシックなどのダイナミックレンジの広い音を聞くにはお勧め。 それでもいて座A*からのブラックホールの輻射ノイズが感じられるという繊細なひとには、ちょっと時間がかかるけど 銀河間の巨大ボイド領域まで出かけていってもらうしかないね。 CPUだとコスパ激悪(安いCPUは2wayできない、2wayできるのはマザーボードもメモリもCPUも高い)だからいくらでも増やせるグラボでエンコードしたいなあ グラボはあればあるだけ高速化できるけど、CPUはAtomでOKみたいな感じで やっぱ人間はダメだよね、心臓の音がうるさくてノイズが乗ってくる。 情弱だがWAVファイルをTTA→APE→FLAC→TAK→TTA→FLACの順にエンコードしても完全無劣化という認識でおk? Opus 128kbpsはVorbis 192kbppsと同等だな >>36 OpusよりVorbisの方がノイズ成分の少ない器楽等は得意だけど、それ以外ならそれくらいの差はあるかもな 金をとるパテントプールがひとつ減ったぞ!やったね! 日本企業が軒並みダークサイドについててワロタ ソニーがAOMに入ってカメラに載せるAV1のHWエンコーダ作るとかそういう話でもあればいいのに オープンソースは無職の仕事 男は黙って商用陣営で家族養え AV1ってDaalaも含まれてるならグラボでエンコードできるのかな 最新のoggenc2.exeをdlしてきてfoobarからVBRで約320kbpsにしたらファイル次第ではflac以上のサイズになってしまった……ABRじゃないんだから 次世代コーデックの本命「AV1」の技術仕様をXiph.Orgが解説 https://gigazine.net/amp/20180411-xiph-explain-av1 フリーの次世代コーデック「Daala」を開発するXiph.Orgは、AOMに加わりAV1の開発に協力しています。 当初、次世代コーデックAV1のベースとなるコーデックに名乗りを上げたのは、Googleの「VP9」、Ciscoの「Thor」そしてXiph.Orgの「Daala」でしたが、既存の特許に抵触するリスクの最も低かったVP9が選出されました。 Xiph.Orgによると、当時、Daalaはラッピングアプローチとクロックドメイン技術の両方が成熟していなかったことからベースコーデックに選ばれなかったとのことで、VP9が選ばれた決定自体は妥当なものだったと考えているそうです。 ベースコーデックに選ばれなかったDaalaですが、同コーデックが取り入れている多くの技術はAV1にも取り入れられているとのこと。 次世代動画コーデック「AV1」の圧縮技術を利用する次世代画像フォーマット「AVIF」 https://gigazine.net/news/20180411-avif-draft/ AV1のエンコード技術を活用することで、高画質&小サイズという高い圧縮率を目指して「AVIF」は開発されています。AVIFはファイル形式(いわゆるコンテナ)であり、AV1以外の圧縮技術も利用できる予定です。 次世代動画コーデックAV1ではHDRやWCG(広色域)技術などがエンコードで反映されていますが、AVIFでもHDRやWCG対応になる予定です。 他にもマスター画像とともにより小さなサイズのサムネイル画像を付加したり、プロパティやメタデータを共用するImage Collectionなどの機能を備えており、画像フォーマットのスタンダードであるJPEGの後継フォーマットとなることを目指して開発が進行中。 2017年12月13日に初期バージョンである「AVIF version 1.0」のドラフトが公開されており、正式リリースの準備が行われています。 なお、以下のサイトではJPEGやX.265のほかにAV1を使った圧縮画像の画質比較が行えます。 AV1 Still Image Comparison https://people.xiph.org/ ~tdaede/av1stilldemo/ 腐るほどお金があるamazonとかnetflixが専用ボードを使って、天文学的な時間がかかるソフトウェアエンコードは 誰もしない。結局2020年になっても個人用途ではx264が主流 とかありそう >xiphがRustで作ってるav1のエンコーダ >リファレンスより速いって書いてある >https://github.com/xiph/rav1e やるぅ! aoTuV beta 6.03 (2018) リリース https://aynote.wordpress.com/2018/05/02/aotuv-beta-6-03-2018%e3%83%aa%e3%83%aa%e3%83%bc%e3%82%b9/ 本家のlibvorbisの新しいバージョン1.3.6がリリースされたため、それと統合したaoTuVを公開しました。 脆弱性の修正がメインとなっており、公式の1.3.5から1.3.6への変更点は以下の通りです。 Fix CVE-2018-5146 ? out-of-bounds write on codebook decoding. Fix CVE-2017-14632 ? free() on unitialized data Fix CVE-2017-14633 ? out-of-bounds read Fix bitrate metadata parsing. Fix out-of-bounds read in codebook parsing. Fix residue vector size in Vorbis I spec. Appveyor support Travis CI support Add secondary CMake build system. Build system fixes 新しいaoTuVについても以上の変更・修正点を反映しているため、ライブラリとしてaoTuVを利用されている場合は旧バージョンからアップデートされることを推奨します。 もちろん公式の1.3.6の代わりに今回のaoTuVを使用することも問題なく可能です。 以下雑談 久しぶりの更新となりました。 今回は前回よりもアップデート作業自体はスムーズに進んだものの、その前段階でPCにトラブルがあったりしたため、 そちらの方に時間が取られてしまい難儀しました。(この辺のお話はそのうち書きたいです) 今回も相変わらずエンコードに影響するような変更は有りません。 コンパイラを更新したこともあり、リファレンスバイナリの出力結果は微妙に異なりますが、コンパイラや実行環境が同じであれば、 同じ出力結果になるはずです。 後は地味にエンコーダのvencの更新をしています。 今回は8/24/32bit整数と32bit浮動小数点のPCM形式の入力に対応したのが主な変更点です。 オーディオデータは32bit浮動小数点数で処理されるため、32bit整数は精度的にはオーバースペックになりますが、 対応してないよりは対応していたほうが良いでしょう。 aoTuV Beta6.03 (2018) (2018/5/2) http://www.geocities.jp/aoyoume/aotuv/index.html # The latest aoTuV beta6.03 was unified with Xiph.Org's libvorbis1.3.6. The part related to sound quality is not changed from previous version. ・ libvorbis 1.3.6を統合しました。エンコード品質については前バージョンと同様です。 3年ぶりの更新か。 MP3の特許が切れ、低ビットレートに強Opusのある今、Vorbisの需要ってどうなんだろう。 むしろMP3のメリットがどんな古い機器でも再生出来るって事しかない だな 古い端末でも希にVorbis再生できたりするがMP3には敵わん ■現時点での有効な選択肢 ・可逆圧縮 FLAC、MPEG4-ALS ・非可逆圧縮 MP3(高ビットレート時)、Opus(中ー低ビットレート時) ・一般人は視聴のみできる非可逆圧縮 MQA ・放送などで普及しているので再生だけは引き続き対応する必要がある非可逆圧縮 AAC、HE-AAC こんな感じか? ABXしてもどうせわからんのだし、特許料要らないFLAC/Opusで全部事足りそう >>55 いやだから、今更MP3を使うメリットなんて無いと言ったのだけど iTunesや窓MPを常用してるのならともかく >>58 横からアレだが、256kbps以上のMP3ならばエンコーダーにもよるけど20kHz以上の音が入ることもあるので、全く無意味というわけではないかと もっとも256kbps以上で保存するならば、MP3以外の選択肢のほうが現実的なのは間違いないけれど 非可逆で20kHz以上を残すことに意味を感じる理由がわからない >>58 古くても良い物はいっぱいあるんだ! HDD_DAPとか まだ修理受け付けてくれるんだぞ! >>60 耳の感度は人によってかなり差があるから当人以外何とも言えない話だけど、出てくる音への影響を考えた場合 ・20kHz以上の周波数帯を含む場合 →ナイキスト周波数の近傍の折返しノイズが出やすい周波数帯も可聴帯域を超えているので折返しノイズとして極めて認知しにくい ・20kHzまでの周波数帯までの場合 →折返しノイズが可聴帯域に入ってくるも、聞き取りにくい周波数帯が主なため、折返しノイズとして認知しにくい(認知しないわけではない) ・16kHzまでの周波数帯までの場合 →もろに可聴帯域内に折返しノイズが入ってくるため、よほど耳の感度が悪くない限り折返しノイズを認知できる という違いはあるので、20kHz以上を含んだからといって無意味なわけではない ただし、一部のハイレゾみたいに40kHz以上の領域が必要かというと、さすがにそれは行き過ぎだとは思うけど 何で22kHzで折り返す前提で話してるのかさっぱり分からない オーバーサンプリング縛りでもしてるのか 最近はopus 160kで統一したわ 泥スマホで普通に聞けるし、何も問題ない Flacと聞き比べしても違いがわからんし libvorbis 1.3.6 (2018-03-16) -- "Xiph.Org libVorbis I 20180316 (Now 100% fewer shells)" * Fix CVE-2018-5146 - out-of-bounds write on codebook decoding. * Fix CVE-2017-14632 - free() on unitialized data * Fix CVE-2017-14633 - out-of-bounds read * Fix bitrate metadata parsing. * Fix out-of-bounds read in codebook parsing. * Fix residue vector size in Vorbis I spec. * Appveyor support * Travis CI support * Add secondary CMake build system. * Build system fixes 音楽ストリーミング配信のコーデックは Apple Music→AAC Spotify→Vorbis YouTube Music→Opus で合ってる? いっぺん聴き比べしてみっかな ついに1.3がβからrcになったな stableもうそろそろか Google Home:HE-AAC,LC-AAC,MP3,Vorbis,WAV(LPCM),FLAC,Opus Google Home mini:HE-AAC,LC-AAC+,MP3,Vorbis,WAV(LPCM),FLAC なぜにOpus省いたし 公式だけどrc版リンクなのでさらに新しいrc fix版(rc2) archive.mozilla.org/pub/opus/win32/opus-tools-test-1.3-rc-fix.zip flacにすると音が悪くなるって書いてあった。あと、タグ付けるとダメとも。 stable消えてrc2になった このまま何もなきゃstableに昇格かな? 密度が減った音になるなー 上下バッサリカットしても濃いmp3のが好き opusを昨日知ったけど160kでメチャクチャいいな ONKYO CMX1程度じゃロスレスと差がわからない。mp3のv0だとわかるんだけど プレイヤーはAndroidだとNeutronで良いのかな >>80-81 FLACにエンコして品質が低下するのであれば、 CD-DA等のソースをまともに吸い出せていないか、 再生環境が低スペックすぎるのではないでしょうか? 前者であれば FLACに限らずどのロスレス形式であっても劣化するはずです。 EAC等のAccurateRip等で照合するソフトで再リップをお勧めします。 後者の場合は、 FLACのビットレートに見合う処理能力を持つスペックの高い環境に替える等するしかありません。 >>88 なんか変なflac派生を使ってパイプ処理してんじゃない? >>91 あれ?10月7日にDLしたんだがopus-tools-0.2-win32.zip 良かったら「opusenc --version」教えてください opusenc opus-tools 0.2-3-gf5f571b (using libopus 1.3) Copyright (C) 2008-2018 Xiph.Org Foundation 今はVorbis再生できる安価ポータブルオーディオプレイヤーがあって良い時代になったもんだ 数千曲から万を超える楽曲をリッピング等してMicroSD等で携帯してる方の 楽曲の管理手法をお聞かせ願えないでしょうか? 私はCD等の音源のバックアップにはEACでリップしたWAVEファイルを ジャケ画像やトラックリスト(テキスト)と共に圧縮アーカイブしてHDDで保管しています。 携帯に関しては全曲をqaacでm4a(AAC-LC)化し、128GBのMicroSDで持ち歩いているのですが、 所持している全CDをリップしたらMicroSDに収まりきらなくなる事が予期できます。 だからといって複数の記憶媒体を携帯したり、抜き差しして運用はしたくないのです。 それならいっその事、SSDで持ち歩いたほうが良いかな?と考えたりしています。 皆さんはどうされてますか? 512MBのmicroSDにすれば4倍入るから 当分は同じ運用でなんとかなるだろ flacに画像も全収納してる wave+cue,logとかあとから見る事がない。 持ち歩きはopus192 今はmicrosd400gbでも安いよ >>101 MBではなくGBです。 >>103 記し忘れました。 普段運用してる機器(一部のタブレットPC)が128GBのmicroSDXCまでなんです。 やはり機器の買い換えを検討したほうが良さそうですね。 ありがとうございました。 ところで、FLACでの運用をしたことないのですが、 qaacやopusencは、そのまま通りますか? もし通るならバックアップはFLACが良いですね。 今は外出先なんで、帰ったら試してみます。 俺はgoogleplaymusicに5万曲upしてストリーミングで聴いてるわ >>108 5万曲!?Opusとかにしてクラウドに上げてんの? サイズどのくらいになるん? >>109 https://support.google.com/googleplaymusic/answer/1100462?hl=ja >各音楽ファイルの最大サイズは 300 MB です。ファイルが MP3 に変換される場合は、変換後の MP3 ファイルにこの 300 MB のサイズ制限が適用されます。 aac,oggは同じビットレートのmp3 FLAC,ALACは320kbpsのmp3に変換されるみたいだね opusは未対応っぽい Opusってタグ管理ですか?wav+cue管理のアルバム.opusは再生不可能...? foobar2000でアルバム毎にエンコードしたらcueシートで分割はできてるみたいですが再生が出来ないんです。 >>111 自決しました 本体とfree enc packを最新版にインストールし直したら、すんなり出来ました。 cueシート管理は一応できるみたいですがよく考えたら意味ないですね opus 256kbpsがmp3,aacの320に相当する品質ということなのでしょうか 512kbpsまで上げられるのですが... >>112 MP3と比較するよりも君がABXで元の音と区別ができなくなるまでビットレートを上げるんや 君の聴力と再生環境によって変わるが、一般には96kbpsで90/100点はあるし、 256kbpsとは言わずその半分の128kbpsでもほぼ区別がつかないかもしれん http://listening-test.coresv.net/results_jp.htm 「自己解決」を「自決」と略すなよ・・・。馬鹿だと思われるぞ。 実際、そう思ったから2行目以降は読み飛ばした。 opusはいくら上げても上下強制カット mp3の320の方が全域出る 不可逆圧縮で人間の耳に聞こえない直流成分や20kHz以上を残すのは大問題や >>116 たとえ聞こえない音でも、エネルギーはあるのだし残さないと音が変わるのでは? ハイレゾは一体何を聴いているのかという話になっちゅうし ハイレゾは別に何も聞いてないよ 聞こえない雑音を残して帯域の無駄遣いしてますってブランド 512kbpsでも若干音が弱いような感じがして何回も聞き直しながらならABXで7回連続くらいはわかった サンプリングレートの違いとか関係あるかねえ >>116 FLACでは残ってて駄目ってこと?不可逆圧縮だとクリップするということでしょうか 確かに音圧バリバリをmp3にエンコするときゲインを下げると音割れしないのだけど関係ありますか >>119 有意水準クリアするにはギリギリのラインでも、10回中9回正解ないしは不正解してないといけないはずだが。 >>117 Xiphの面々はリスニング用途でのハイレゾには懐疑的や https://people.xiph.org/ ~xiphmont/demo/neil-young.html >>120 可逆圧縮では元と完全一致せんとアカン 音割れはどうにもならんが再生時のReplayGainでマシにはなる >>122 無駄にファイルサイズが大きくなるし単なるリスナーにとっては恩恵が少ないよね CD音質でも音量稼がなきゃ 前から気になってたのだけど replaygainとmp3gainが音源は弄らずタグに再生時の音量を埋め込んで 音量の均一化とクリッピングを防ぐのも目的なのは分かるけど 元から最大音量ぎりぎりの音圧高い音源を非可逆圧縮に変換するときに 波形処理でクリッピングを起こすという記事を見て 後からのgain調整じゃ圧縮音源に変換した際のクリッピングは防げないし 元の音源の音量を下げてから変換したときの方が 変換後gain調整よりも音質が良くなるのでは?? 音圧戦争対策のツールで四角い波形からダイナミクスレンジとヘッドルーム確保したらすっきりすると思うのですが いやしかし、波形を弄る以上確実に変化してしまうし とにかくmp3に変換するときのクリッピングを防ぎたい ワイみたいにクラヲタにでもなるか、録音のましな1980年代のCDを探すしか無いわな クラシックみたいにダイナミックレンジの広い楽曲の時は量子化ビット数が大きいほうが良いかもね。サンプリング周波数は別として。 世の中の殆どの人がCD可逆どころか256kbpsAACで満足してる現状ハイレゾはオーバースペック >>126 一部のマニア向けのスペックは有っても良いんじゃね? 誰もハイレゾがデファクトスタンダードになるとは思ってないよ ドルビーアトモスを誰もオーバースペックなどと言わないだろ AACからOpusに変換するのは抵抗があるからPCMあるいはその可逆圧縮を買いたいわ RAREWARESに有るファイルが更新されています。 >>126 いや、それどころか世の中のほとんどの人は128kbpsMP3で満足してるから ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる