【Opus/Vorbis/FLAC】Ogg統合20【AV1/Theora】
Xiph.Org Foundation（ザイフォ財団）により運営されている
パテントフリー、オープンソースのマルチメディアプロジェクト
コアライブラリには修正BSDライセンスを採用しており、
商用非商用関係なく、使用・配布など全てを自由に行えるのが特徴
【前スレ】
【Vorbis/FLAC】Ogg統合19【Theora/etc...】
http://egg.2ch.sc/test/read.cgi/software/1393839807/
テンプレ前のそのままはアカンよね。結構動きあったし前スレ建ったの2014/03/03だし
Lilithみたいな情弱プレイヤーなんて誰も使ってないだろうし
加えて言うとスレ一個消費するのに4年も要してるのでテンプレ類はいらん
更新されたらその都度従来通りURLを貼っていけばいいと思われる
乙なんよ
?
「RareWares」（エンコーダ・デコーダ、ツール、バイナリを配布）
http://www.rarewares.org/
aoTuV（Vorbis派生エンコーダ）
http://www.geocities.jp/aoyoume/
Wikipedia (JP)
https://ja.wikipedia.org/wiki/Xiph.Org_Foundation
Hydrogenaudio Forum
https://hydrogenaud.io/index.php?action=forum
Web メディア拡張機能
https://www.microsoft.com/ja-jp/store/p/web/9n5tdp8vcmhs
QuickTime Components
https://www.xiph.org/quicktime/
まぁ、初代スレからいるんでここで語りたいが
なにコレめんどくさーい
音声コーデックのコンテナとしてのOggは、DTV板とあまり関連が無い
VP8やVP9がオープンソースになってからのTheoraを語るのも不毛だし
うーん、糞耳w
mp3は lame -V 0 で十分だし
一度音割れさせてしまうともうだめだな
対するOpusはMDCTの構造から言ってもこういうのは得意
http://lame.sourceforge.net/download/samples/
「Groove ミュージック」や「映画 & テレビ」で再生できる
拡張子をwmaにすれば「プログラムから開く」から「Groove ミュージック」で再生できる
拡張子をwmvかasfにすれば「プログラムから開く」から「映画 & テレビ」で再生できる
コマンド例
ffmpeg -i input.mp4 -vn -c:a libopus -atag 0x704F -f asf output.asf
参考 WAVE_FORMAT_OPUS (0x704F)
https://msdn.microsoft.com/ja-jp/library/windows/desktop/aa372553(v=vs.85).aspx
無音とか多いから無駄なんだよなぁ。
320CBRだとFLACよりでかくなったりすることも多いので頭悪い
-V 0にしてほしい
さいつよはOpusだけど
これはCBRのMP3から音質に影響の無い詰め物を取ってVBRを実現するソフトみたいね
MP3 repacker
https://hydrogenaud.io/index.php/topic,32379.0.html
衆議員と参議院の両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
これはMP3を音質変化なく圧縮できるってことかな？
使えそう
https://gigazine.net/news/20180215-mpeg2-patent-expired/
2018年2月13日にアメリカで残っていた最後のMPEG2に関する特許が期限切れを迎えました。
MPEG-2 Patent List
http://www.mpegla.com/main/programs/M2/Pages/PatentList.aspx
MPEG2はMoving Picture Experts Group(MPEG)によって策定されたビデオフォーマットで、テレビ放送やDVDなどのメディアなどに広く利用される、最も一般的なビデオ標準規格です。
MPEG2の特許を管理するパテントプールのMPEG LAがMPEG-2の特許リストを更新し、2018年2月13日にアメリカ国内で残っていた最後の特許が期限切れを迎えたことを明らかにしました。
（ ＾ω＾）
というかAoMがAV1専用HWエンコーダでも出してくれないかなあ
24kHzでもやってみたらアタック性の強い音なら区別できたけど、単独で聞かされたら違和感ない気がする
結局96kHzとか192kHzとかって無意味極まりない感しかない
ビット深度は浮動小数点でミックスでマージンに余裕がとれるとかメリットがあるけど
聴く側からしたらAC97で強制リサンプリングがない48/24が一番マシだよね
「うわ耳がやられた！」
「えっ？」
「えっ？」
冥王星程度まで離れるとかなり静かな環境なんで、クラッシックなどのダイナミックレンジの広い音を聞くにはお勧め。
それでもいて座A*からのブラックホールの輻射ノイズが感じられるという繊細なひとには、ちょっと時間がかかるけど
銀河間の巨大ボイド領域まで出かけていってもらうしかないね。
グラボはあればあるだけ高速化できるけど、CPUはAtomでOKみたいな感じで
別にその順番でなくてもそう
OpusよりVorbisの方がノイズ成分の少ない器楽等は得意だけど、それ以外ならそれくらいの差はあるかもな
https://pc.watch.impress.co.jp/docs/news/1111623.html
ソニーがAOMに入ってカメラに載せるAV1のHWエンコーダ作るとかそういう話でもあればいいのに
男は黙って商用陣営で家族養え
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にも取り入れられているとのこと。
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/
誰もしない。結局2020年になっても個人用途ではx264が主流
とかありそう
>リファレンスより速いって書いてある
>https://github.com/xiph/rav1e
やるぅ！
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整数は精度的にはオーバースペックになりますが、
対応してないよりは対応していたほうが良いでしょう。
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を統合しました。エンコード品質については前バージョンと同様です。
MP3の特許が切れ、低ビットレートに強Opusのある今、Vorbisの需要ってどうなんだろう。
古い端末でも希にVorbis再生できたりするがMP3には敵わん
・可逆圧縮
FLAC、MPEG4-ALS
・非可逆圧縮
MP3（高ビットレート時）、Opus（中ー低ビットレート時）
・一般人は視聴のみできる非可逆圧縮
MQA
・放送などで普及しているので再生だけは引き続き対応する必要がある非可逆圧縮
AAC、HE-AAC
こんな感じか？
いやだから、今更MP3を使うメリットなんて無いと言ったのだけど
iTunesや窓MPを常用してるのならともかく
横からアレだが、256kbps以上のMP3ならばエンコーダーにもよるけど20kHz以上の音が入ることもあるので、全く無意味というわけではないかと
もっとも256kbps以上で保存するならば、MP3以外の選択肢のほうが現実的なのは間違いないけれど
古くても良い物はいっぱいあるんだ！
HDD_DAPとか
まだ修理受け付けてくれるんだぞ！
耳の感度は人によってかなり差があるから当人以外何とも言えない話だけど、出てくる音への影響を考えた場合
・20kHz以上の周波数帯を含む場合
→ナイキスト周波数の近傍の折返しノイズが出やすい周波数帯も可聴帯域を超えているので折返しノイズとして極めて認知しにくい
・20kHzまでの周波数帯までの場合
→折返しノイズが可聴帯域に入ってくるも、聞き取りにくい周波数帯が主なため、折返しノイズとして認知しにくい（認知しないわけではない）
・16kHzまでの周波数帯までの場合
→もろに可聴帯域内に折返しノイズが入ってくるため、よほど耳の感度が悪くない限り折返しノイズを認知できる
という違いはあるので、20kHz以上を含んだからといって無意味なわけではない
ただし、一部のハイレゾみたいに40kHz以上の領域が必要かというと、さすがにそれは行き過ぎだとは思うけど
オーバーサンプリング縛りでもしてるのか
スケールファクタに制限のあるMP3と言う規格で16kHz以上を保持しようとすると、それ未満の帯域が犠牲になる
http://wiki.hydrogenaud.io/index.php?title=High-frequency_content_in_MP3s
泥スマホで普通に聞けるし、何も問題ない
Flacと聞き比べしても違いがわからんし
* 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
http://www.geocities.jp/aoyoume/aotuv/
こっちも
Apple Music→AAC
Spotify→Vorbis
YouTube Music→Opus
で合ってる？
いっぺん聴き比べしてみっかな
stableもうそろそろか
Google Home mini:HE-AAC,LC-AAC+,MP3,Vorbis,WAV(LPCM),FLAC
なぜにOpus省いたし
archive.mozilla.org/pub/opus/win32/opus-tools-test-1.3-rc-fix.zip
オカルト
このまま何もなきゃstableに昇格かな？
上下バッサリカットしても濃いmp3のが好き
ONKYO CMX1程度じゃロスレスと差がわからない。mp3のv0だとわかるんだけど
プレイヤーはAndroidだとNeutronで良いのかな
気のせい
mp3が濃いとか意味不明
FLACにエンコして品質が低下するのであれば、
CD-DA等のソースをまともに吸い出せていないか、
再生環境が低スペックすぎるのではないでしょうか？
前者であれば
FLACに限らずどのロスレス形式であっても劣化するはずです。
EAC等のAccurateRip等で照合するソフトで再リップをお勧めします。
後者の場合は、
FLACのビットレートに見合う処理能力を持つスペックの高い環境に替える等するしかありません。
なんか変なflac派生を使ってパイプ処理してんじゃない？
HelixのMP3は悪くはないですよ。
https://archive.mozilla.org/pub/opus/win32/opus-tools-0.2-opus-1.3.zip
https://archive.mozilla.org/pub/opus/win64/opus-tools-0.2-opus-1.3-win64.zip
あれ？10月7日にDLしたんだがopus-tools-0.2-win32.zip
良かったら「opusenc --version」教えてください
Copyright (C) 2008-2018 Xiph.Org Foundation
Core i7 6700では変わらず
http://www.mediafire.com/file/221rzevd8ndt0a4/opus-1.3-win64-generic.7z/file
http://www.mediafire.com/file/89a8ancfnc02rsb/opus-1.3-win32-pentium3.7z/file
FLACのデコーダーがデコード(再生)できてる訳なので、それはない気がしますよ。
音質を下げる嫌がらせFLACエンコーダーとか想像したら笑えますけどね。
libvorbis新版こねえなー
http://www.mediafire.com/file/3pweg533ztfs79g/oggenc-libvorbis-1.3.6-win64-generic.7z/file
100〜のスレッドの続きを読む
