【Opus/Vorbis/FLAC】Ogg統合20【AV1/Theora】

**名無しさん＠お腹いっぱい。** · 2018/01/27(土) 13:32:37.91

http://www.xiph.org/
Xiph.Org Foundation（ザイフォ財団）により運営されている
パテントフリー、オープンソースのマルチメディアプロジェクト
コアライブラリには修正BSDライセンスを採用しており、
商用非商用関係なく、使用・配布など全てを自由に行えるのが特徴

【前スレ】
【Vorbis/FLAC】Ogg統合19【Theora/etc...】
http://egg.5ch.net/test/read.cgi/software/1393839807/

**名無しさん＠お腹いっぱい。** · 2018/03/22(木) 14:28:05.69

オープンソースは無職の仕事
男は黙って商用陣営で家族養え

**名無しさん＠お腹いっぱい。** · 2018/03/23(金) 01:01:09.50

そう、Atrac3です。

**名無しさん＠お腹いっぱい。** · 2018/03/23(金) 21:00:20.62

AV1ってDaalaも含まれてるならグラボでエンコードできるのかな

**名無しさん＠お腹いっぱい。** · 2018/04/01(日) 00:17:11.37

最新のoggenc2.exeをdlしてきてfoobarからVBRで約320kbpsにしたらファイル次第ではflac以上のサイズになってしまった……ABRじゃないんだから

**名無しさん＠お腹いっぱい。** · 2018/04/13(金) 15:27:22.34

次世代コーデックの本命「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にも取り入れられているとのこと。

**名無しさん＠お腹いっぱい。** · 2018/04/13(金) 15:39:44.06

次世代動画コーデック「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/

**名無しさん＠お腹いっぱい。** · 2018/04/13(金) 20:20:51.47

腐るほどお金があるamazonとかnetflixが専用ボードを使って、天文学的な時間がかかるソフトウェアエンコードは
誰もしない。結局2020年になっても個人用途ではx264が主流

とかありそう

**名無しさん＠お腹いっぱい。** · 2018/04/18(水) 12:21:24.98

>xiphがRustで作ってるav1のエンコーダ
>リファレンスより速いって書いてある
>https://github.com/xiph/rav1e

やるぅ！

**名無しさん＠お腹いっぱい。** · 2018/05/03(木) 01:18:01.62

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を使用することも問題なく可能です。

**名無しさん＠お腹いっぱい。** · 2018/05/03(木) 01:19:51.11

以下雑談

久しぶりの更新となりました。

今回は前回よりもアップデート作業自体はスムーズに進んだものの、その前段階でPCにトラブルがあったりしたため、
そちらの方に時間が取られてしまい難儀しました。（この辺のお話はそのうち書きたいです）

今回も相変わらずエンコードに影響するような変更は有りません。
コンパイラを更新したこともあり、リファレンスバイナリの出力結果は微妙に異なりますが、コンパイラや実行環境が同じであれば、
同じ出力結果になるはずです。

後は地味にエンコーダのvencの更新をしています。
今回は8/24/32bit整数と32bit浮動小数点のPCM形式の入力に対応したのが主な変更点です。
オーディオデータは32bit浮動小数点数で処理されるため、32bit整数は精度的にはオーバースペックになりますが、
対応してないよりは対応していたほうが良いでしょう。

**名無しさん＠お腹いっぱい。** · 2018/05/03(木) 01:21:40.35

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を統合しました。エンコード品質については前バージョンと同様です。

**名無しさん＠お腹いっぱい。** · 2018/05/03(木) 03:17:14.46

3年ぶりの更新か。
MP3の特許が切れ、低ビットレートに強Opusのある今、Vorbisの需要ってどうなんだろう。

**名無しさん＠お腹いっぱい。** · 2018/05/03(木) 10:10:45.52

むしろMP3のメリットがどんな古い機器でも再生出来るって事しかない

**名無しさん＠お腹いっぱい。** · 2018/05/03(木) 12:30:57.10

だな
古い端末でも希にVorbis再生できたりするがMP3には敵わん

**名無しさん＠お腹いっぱい。** · 2018/05/03(木) 13:15:22.85

■現時点での有効な選択肢

・可逆圧縮
FLAC、MPEG4-ALS
・非可逆圧縮
MP3（高ビットレート時）、Opus（中ー低ビットレート時）

・一般人は視聴のみできる非可逆圧縮
MQA

・放送などで普及しているので再生だけは引き続き対応する必要がある非可逆圧縮
AAC、HE-AAC

こんな感じか？

**名無しさん＠お腹いっぱい。** · 2018/05/03(木) 13:55:57.54

ABXしてもどうせわからんのだし、特許料要らないFLAC/Opusで全部事足りそう

**名無しさん＠お腹いっぱい。** · 2018/05/03(木) 14:06:40.18

>>55
いやだから、今更MP3を使うメリットなんて無いと言ったのだけど
iTunesや窓MPを常用してるのならともかく

**名無しさん＠お腹いっぱい。** · 2018/05/03(木) 14:12:39.15

>>58
横からアレだが、256kbps以上のMP3ならばエンコーダーにもよるけど20kHz以上の音が入ることもあるので、全く無意味というわけではないかと
もっとも256kbps以上で保存するならば、MP3以外の選択肢のほうが現実的なのは間違いないけれど

**名無しさん＠お腹いっぱい。** · 2018/05/03(木) 14:46:51.72

非可逆で20kHz以上を残すことに意味を感じる理由がわからない

**名無しさん＠お腹いっぱい。** · 2018/05/03(木) 14:58:49.99

>>58
古くても良い物はいっぱいあるんだ！
HDD_DAPとか
まだ修理受け付けてくれるんだぞ！

**名無しさん＠お腹いっぱい。** · 2018/05/03(木) 17:00:06.20

>>60
耳の感度は人によってかなり差があるから当人以外何とも言えない話だけど、出てくる音への影響を考えた場合

・20kHz以上の周波数帯を含む場合
→ナイキスト周波数の近傍の折返しノイズが出やすい周波数帯も可聴帯域を超えているので折返しノイズとして極めて認知しにくい

・20kHzまでの周波数帯までの場合
→折返しノイズが可聴帯域に入ってくるも、聞き取りにくい周波数帯が主なため、折返しノイズとして認知しにくい（認知しないわけではない）

・16kHzまでの周波数帯までの場合
→もろに可聴帯域内に折返しノイズが入ってくるため、よほど耳の感度が悪くない限り折返しノイズを認知できる

という違いはあるので、20kHz以上を含んだからといって無意味なわけではない
ただし、一部のハイレゾみたいに40kHz以上の領域が必要かというと、さすがにそれは行き過ぎだとは思うけど

**名無しさん＠お腹いっぱい。** · 2018/05/03(木) 17:15:44.38

何で22kHzで折り返す前提で話してるのかさっぱり分からない
オーバーサンプリング縛りでもしてるのか

**名無しさん＠お腹いっぱい。** · 2018/05/03(木) 17:19:36.39

無理にわかる必要はないよ

**名無しさん＠お腹いっぱい。** · 2018/05/03(木) 18:14:36.44

opusは20kHzカットだったな

**名無しさん＠お腹いっぱい。** · 2018/05/04(金) 16:29:41.04

opusは思いきりが良すぎ

**名無しさん＠お腹いっぱい。** · 2018/05/05(土) 00:32:47.27

iphoneでflac使ってる香具師おる？

**名無しさん＠お腹いっぱい。転載ダメ** · 2018/05/05(土) 14:33:18.68

>>59
スケールファクタに制限のあるMP3と言う規格で16kHz以上を保持しようとすると、それ未満の帯域が犠牲になる

http://wiki.hydrogenaud.io/index.php?title=High-frequency_content_in_MP3s

**名無しさん＠お腹いっぱい。** · 2018/05/08(火) 01:35:15.03

最近はopus 160kで統一したわ
泥スマホで普通に聞けるし、何も問題ない
Flacと聞き比べしても違いがわからんし

**名無しさん＠お腹いっぱい。** · 2018/05/10(木) 19:22:58.78

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

**名無しさん＠お腹いっぱい。** · 2018/05/10(木) 21:15:17.30

>>70
http://www.geocities.jp/aoyoume/aotuv/
こっちも

**名無しさん＠お腹いっぱい。** · 2018/05/29(火) 22:13:55.10

音楽ストリーミング配信のコーデックは
Apple Music→AAC
Spotify→Vorbis
YouTube Music→Opus

で合ってる？
いっぺん聴き比べしてみっかな

**名無しさん＠お腹いっぱい。** · 2018/06/07(木) 12:56:06.10

ついに1.3がβからrcになったな
stableもうそろそろか

**名無しさん＠お腹いっぱい。** · 2018/07/04(水) 13:26:48.33

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省いたし

**名無しさん＠お腹いっぱい。** · 2018/07/04(水) 14:49:14.90

miniですから

**名無しさん＠お腹いっぱい。** · 2018/08/03(金) 23:59:08.45

opus

**名無しさん＠お腹いっぱい。** · 2018/08/12(日) 08:58:55.70

公式だけどrc版リンクなのでさらに新しいrc fix版(rc2)
archive.mozilla.org/pub/opus/win32/opus-tools-test-1.3-rc-fix.zip

**名無しさん＠お腹いっぱい。** · 2018/08/12(日) 14:48:26.98

もう古いよ

**名無しさん＠お腹いっぱい。** · 2018/08/17(金) 18:52:34.22

えっ

**名無しさん＠お腹いっぱい。** · 2018/09/07(金) 17:35:16.68

flacにすると音が悪くなるって書いてあった。あと、タグ付けるとダメとも。

**名無しさん＠お腹いっぱい。** · 2018/09/07(金) 20:53:00.62

>>80
オカルト

**名無しさん＠お腹いっぱい。** · 2018/09/20(木) 03:52:35.82

opus-tools 0.2が出ました

**名無しさん＠お腹いっぱい。** · 2018/09/20(木) 20:39:15.52

stable消えてrc2になった
このまま何もなきゃstableに昇格かな？

**名無しさん＠お腹いっぱい。** · 2018/09/22(土) 07:20:36.52

密度が減った音になるなー
上下バッサリカットしても濃いmp3のが好き

**名無しさん＠お腹いっぱい。** · 2018/09/25(火) 15:47:32.52

opusを昨日知ったけど160kでメチャクチャいいな
ONKYO CMX1程度じゃロスレスと差がわからない。mp3のv0だとわかるんだけど
プレイヤーはAndroidだとNeutronで良いのかな

**名無しさん＠お腹いっぱい。** · 2018/09/26(水) 17:20:55.12

>>85
気のせい

**名無しさん＠お腹いっぱい。** · 2018/09/30(日) 13:43:39.46

>>84
mp3が濃いとか意味不明

**名無しさん＠お腹いっぱい。** · 2018/10/01(月) 17:12:07.53

>>80-81
FLACにエンコして品質が低下するのであれば、
CD-DA等のソースをまともに吸い出せていないか、
再生環境が低スペックすぎるのではないでしょうか？

前者であれば
FLACに限らずどのロスレス形式であっても劣化するはずです。
EAC等のAccurateRip等で照合するソフトで再リップをお勧めします。

後者の場合は、
FLACのビットレートに見合う処理能力を持つスペックの高い環境に替える等するしかありません。

**名無しさん＠お腹いっぱい。** · 2018/10/01(月) 17:59:48.39

>>88
なんか変なflac派生を使ってパイプ処理してんじゃない？

**名無しさん＠お腹いっぱい。** · 2018/10/06(土) 22:58:21.31

>>87
HelixのMP3は悪くはないですよ。

**名無しさん＠お腹いっぱい。** · 2018/10/19(金) 15:26:07.01

Opus 1.3
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

**名無しさん＠お腹いっぱい。** · 2018/10/19(金) 16:54:49.05

>>91
あれ？10月7日にDLしたんだがopus-tools-0.2-win32.zip
良かったら「opusenc --version」教えてください

**名無しさん＠お腹いっぱい。** · 2018/10/19(金) 17:46:17.11

opusenc opus-tools 0.2-3-gf5f571b (using libopus 1.3)
Copyright (C) 2008-2018 Xiph.Org Foundation

**名無しさん＠お腹いっぱい。転載ダメ** · 2018/10/20(土) 17:09:04.05

FX-8150では>>91より5%程こちらが速い
Core i7 6700では変わらず

http://www.mediafire.com/file/221rzevd8ndt0a4/opus-1.3-win64-generic.7z/file

**名無しさん＠お腹いっぱい。転載ダメ** · 2018/10/20(土) 21:28:59.51

これはAtom Z8300で公式バイナリよりも12%速い

http://www.mediafire.com/file/89a8ancfnc02rsb/opus-1.3-win32-pentium3.7z/file

**名無しさん＠お腹いっぱい。** · 2018/10/25(木) 00:09:01.26

http://www.rarewares.org/

libvorbis新版こねえなー

**名無しさん＠お腹いっぱい。** · 2018/10/26(金) 21:05:06.22

今はVorbis再生できる安価ポータブルオーディオプレイヤーがあって良い時代になったもんだ

**名無しさん＠お腹いっぱい。転載ダメ** · 2018/10/29(月) 23:51:52.24

パッチ無しの素のoggencのみ

http://www.mediafire.com/file/3pweg533ztfs79g/oggenc-libvorbis-1.3.6-win64-generic.7z/file

**名無しさん＠お腹いっぱい。転載ダメ** · 2018/10/30(火) 00:18:39.84

こっちはaoTuV

http://www.mediafire.com/file/a5j65875juhm520/oggenc-aoTuV-b6.03-libvorbis-1.3.6-win64-generic.7z/file

**名無しさん＠お腹いっぱい。** · 2018/11/11(日) 00:26:07.48

数千曲から万を超える楽曲をリッピング等してMicroSD等で携帯してる方の
楽曲の管理手法をお聞かせ願えないでしょうか？

私はCD等の音源のバックアップにはEACでリップしたWAVEファイルを
ジャケ画像やトラックリスト(テキスト)と共に圧縮アーカイブしてHDDで保管しています。
携帯に関しては全曲をqaacでm4a(AAC-LC)化し、128GBのMicroSDで持ち歩いているのですが、
所持している全CDをリップしたらMicroSDに収まりきらなくなる事が予期できます。
だからといって複数の記憶媒体を携帯したり、抜き差しして運用はしたくないのです。
それならいっその事、SSDで持ち歩いたほうが良いかな？と考えたりしています。

皆さんはどうされてますか？

**名無しさん＠お腹いっぱい。** · 2018/11/11(日) 07:52:43.52

512MBのmicroSDにすれば4倍入るから
当分は同じ運用でなんとかなるだろ

**名無しさん＠お腹いっぱい。** · 2018/11/11(日) 08:38:05.03

小さくしすぎ

**名無しさん＠お腹いっぱい。** · 2018/11/11(日) 10:05:58.02

flacに画像も全収納してる
wave+cue,logとかあとから見る事がない。

持ち歩きはopus192
今はmicrosd400gbでも安いよ

**名無しさん＠お腹いっぱい。** · 2018/11/11(日) 11:24:30.90

ビットレートを半分にすれば実質256倍は入るな

**名無しさん＠お腹いっぱい。** · 2018/11/11(日) 11:24:39.27

>>101
MBではなくGBです。

>>103
記し忘れました。
普段運用してる機器(一部のタブレットPC)が128GBのmicroSDXCまでなんです。

やはり機器の買い換えを検討したほうが良さそうですね。
ありがとうございました。

ところで、FLACでの運用をしたことないのですが、
qaacやopusencは、そのまま通りますか？
もし通るならバックアップはFLACが良いですね。
今は外出先なんで、帰ったら試してみます。

**名無しさん＠お腹いっぱい。** · 2018/11/11(日) 11:58:44.75

>>96
来たよ

**名無しさん＠お腹いっぱい。** · 2018/11/11(日) 12:46:57.80

数千から万って・・・皆そんな持ってんの？すげーな

**名無しさん＠お腹いっぱい。** · 2018/11/11(日) 13:42:43.31

俺はgoogleplaymusicに5万曲upしてストリーミングで聴いてるわ

**名無しさん＠お腹いっぱい。** · 2018/11/11(日) 14:14:52.29

>>108
5万曲！？Opusとかにしてクラウドに上げてんの？
サイズどのくらいになるん？

**名無しさん＠お腹いっぱい。** · 2018/11/11(日) 14:39:01.07

>>109
https://support.google.com/googleplaymusic/answer/1100462?hl=ja
>各音楽ファイルの最大サイズは 300 MB です。ファイルが MP3 に変換される場合は、変換後の MP3 ファイルにこの 300 MB のサイズ制限が適用されます。

aac,oggは同じビットレートのmp3
FLAC,ALACは320kbpsのmp3に変換されるみたいだね
opusは未対応っぽい

**名無しさん＠お腹いっぱい。** · 2018/11/13(火) 22:36:05.56

Opusってタグ管理ですか？wav+cue管理のアルバム.opusは再生不可能...?

foobar2000でアルバム毎にエンコードしたらcueシートで分割はできてるみたいですが再生が出来ないんです。

**111** · 2018/11/15(木) 01:27:25.83

>>111自決しました
本体とfree enc packを最新版にインストールし直したら、すんなり出来ました。

cueシート管理は一応できるみたいですがよく考えたら意味ないですね

opus 256kbpsがmp3,aacの320に相当する品質ということなのでしょうか
512kbpsまで上げられるのですが...

**名無しさん＠お腹いっぱい。転載ダメ** · 2018/11/15(木) 08:35:36.30

>>112
MP3と比較するよりも君がABXで元の音と区別ができなくなるまでビットレートを上げるんや

君の聴力と再生環境によって変わるが、一般には96kbpsで90/100点はあるし、
256kbpsとは言わずその半分の128kbpsでもほぼ区別がつかないかもしれん

http://listening-test.coresv.net/results_jp.htm

**名無しさん＠お腹いっぱい。** · 2018/11/15(木) 08:37:55.36

「自己解決」を「自決」と略すなよ･･･。馬鹿だと思われるぞ。

実際、そう思ったから2行目以降は読み飛ばした。

**名無しさん＠お腹いっぱい。** · 2018/11/15(木) 08:52:51.98

opusはいくら上げても上下強制カット
mp3の320の方が全域出る

**名無しさん＠お腹いっぱい。転載ダメ** · 2018/11/15(木) 11:49:32.22

不可逆圧縮で人間の耳に聞こえない直流成分や20kHz以上を残すのは大問題や

**名無しさん＠お腹いっぱい。** · 2018/11/15(木) 15:50:45.76

>>116
たとえ聞こえない音でも、エネルギーはあるのだし残さないと音が変わるのでは？
ハイレゾは一体何を聴いているのかという話になっちゅうし

**名無しさん＠お腹いっぱい。** · 2018/11/15(木) 16:40:12.72

ハイレゾは別に何も聞いてないよ
聞こえない雑音を残して帯域の無駄遣いしてますってブランド

**名無しさん＠お腹いっぱい。** · 2018/11/15(木) 18:37:13.29

512kbpsでも若干音が弱いような感じがして何回も聞き直しながらならABXで7回連続くらいはわかった
サンプリングレートの違いとか関係あるかねえ

**>>111自決** · 2018/11/15(木) 19:10:25.02

>>116
FLACでは残ってて駄目ってこと？不可逆圧縮だとクリップするということでしょうか

確かに音圧バリバリをmp3にエンコするときゲインを下げると音割れしないのだけど関係ありますか

**名無しさん＠お腹いっぱい。** · 2018/11/15(木) 23:17:05.61

>>119
有意水準クリアするにはギリギリのラインでも、10回中9回正解ないしは不正解してないといけないはずだが。

**名無しさん＠お腹いっぱい。転載ダメ** · 2018/11/16(金) 15:26:59.78

>>117
Xiphの面々はリスニング用途でのハイレゾには懐疑的や
https://people.xiph.org/~xiphmont/demo/neil-young.html

>>120
可逆圧縮では元と完全一致せんとアカン

音割れはどうにもならんが再生時のReplayGainでマシにはなる

**名無しさん＠お腹いっぱい。** · 2018/11/16(金) 17:32:13.29

>>122
無駄にファイルサイズが大きくなるし単なるリスナーにとっては恩恵が少ないよね
CD音質でも音量稼がなきゃ

前から気になってたのだけど
replaygainとmp3gainが音源は弄らずタグに再生時の音量を埋め込んで
音量の均一化とクリッピングを防ぐのも目的なのは分かるけど

元から最大音量ぎりぎりの音圧高い音源を非可逆圧縮に変換するときに
波形処理でクリッピングを起こすという記事を見て
後からのgain調整じゃ圧縮音源に変換した際のクリッピングは防げないし

元の音源の音量を下げてから変換したときの方が変換後gain調整よりも音質が良くなるのでは？？
音圧戦争対策のツールで四角い波形からダイナミクスレンジとヘッドルーム確保したらすっきりすると思うのですが

いやしかし、波形を弄る以上確実に変化してしまうし
とにかくmp3に変換するときのクリッピングを防ぎたい

**名無しさん＠お腹いっぱい。転載ダメ** · 2018/11/16(金) 22:53:43.62

ワイみたいにクラヲタにでもなるか、録音のましな1980年代のCDを探すしか無いわな

**名無しさん＠お腹いっぱい。** · 2018/11/17(土) 08:05:14.31

クラシックみたいにダイナミックレンジの広い楽曲の時は量子化ビット数が大きいほうが良いかもね。サンプリング周波数は別として。

**名無しさん＠お腹いっぱい。** · 2018/11/17(土) 08:20:14.70

世の中の殆どの人がCD可逆どころか256kbpsAACで満足してる現状ハイレゾはオーバースペック

**名無しさん＠お腹いっぱい。** · 2018/11/17(土) 08:39:59.68

>>126
一部のマニア向けのスペックは有っても良いんじゃね？
誰もハイレゾがデファクトスタンダードになるとは思ってないよ
ドルビーアトモスを誰もオーバースペックなどと言わないだろ

**名無しさん＠お腹いっぱい。転載ダメ** · 2018/11/17(土) 09:39:07.94

AACからOpusに変換するのは抵抗があるからPCMあるいはその可逆圧縮を買いたいわ

**名無しさん＠お腹いっぱい。** · 2018/11/17(土) 12:23:20.47

>>123
すまんスレ違いだった

**名無しさん＠お腹いっぱい。** · 2018/11/19(月) 17:03:27.44

RAREWARESに有るファイルが更新されています。

**名無しさん＠お腹いっぱい。** · 2018/11/25(日) 04:53:02.11

>>126
いや、それどころか世の中のほとんどの人は128kbpsMP3で満足してるから

**名無しさん＠お腹いっぱい。転載ダメ** · 2018/11/25(日) 11:44:24.85

最近は光学ドライブの無いPCが増えた結果自分でリッピングする人も減って
SpotifyのVorbis 96kbpsで満足する人も多いんちゃうか

**名無しさん＠お腹いっぱい。** · 2018/11/25(日) 11:59:25.39

　　　　　　　　　　　　　　　　　　　 |
　　　　　　　　　　　　　　　　　　　 |
　　　　　 ∩＿＿＿∩　　　　　　　　　 |
　　　　　 | ノ　 _,　　,_ ヽ　　　　　　（（　 |　ﾌﾟﾗﾌﾟﾗ
　　　　 /　　●　　　● |　　　　　　　　　(=)
　　　　 |　　　　( _●_)　ミ　＿　(⌒)　　J　　））
　　　　彡､　　　|∪|　ノ
⊂⌒ヽ　/　　　ヽノ　ヽ /⌒つ
　＼　ヽ　 /　　　　　ヽ　/
　　　＼_,,ノ　　　　　　|､＿ノ 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b)

**名無しさん＠お腹いっぱい。** · 2018/12/07(金) 06:44:00.36

>>131
プレイヤー環境変えた瞬間、こんな音悪かったんだって皆言うけどね。
DL派だったやつもCD買ったりレンタルしだす。

ハイレゾは良いけど、DL販売はひとまず、CD音源とかそのまま売ってくれって思う。

**名無しさん＠お腹いっぱい。** · 2018/12/07(金) 06:49:17.82

>>134
↑に補足。あとCDと大した値段変えないなら、
アルバムアートとかのブックレット画像全部付けろって思う。

**名無しさん＠お腹いっぱい。** · 2018/12/11(火) 14:00:18.86

Super Smash Bros. Ultimate Would Have Required Close To 30GB If They Didn’t Compress The Music
https://nintendosoup.com/super-smash-bros-ultimate-would-have-required-close-to-30gb-if-they-didnt-compress-the-music/
>the lopus codec, an audio compression format rarely used by the end consumer. With the lopus codec, the total file size of the thousand or so musical tracks tallied up to 1GB+.
If they didn’t go with the lopus codec, things would have been disastrous – if they used WAV, the file size of all music would have ballooned up to 13GB.
If MP3 was used instead, it’d have been 8GB. For reference, 13GB is almost the same size as the entire game itself (adding the game and WAV files up is 27GB), so you can tell how important the task was to compress all the music.

the lopus codec = Opus?

**名無しさん＠お腹いっぱい。** · 2018/12/11(火) 14:16:49.17

ゲーム開発向けの統合型サウンドミドルウェアWwiseのOpusサポート
https://blog.audiokinetic.com/ja/wwise-2018.1/
OPUSコーデックが、全プラットフォームでサポートされています。Opusは、CPUを少し余分に確保するだけでWwise Vorbisに匹敵する品質を保ちつつ、さらに圧縮できるので、ファイルサイズを特に縮小する必要があるときは、Wwise Vorbisの代替案として非常に有効です。
これらのコーデックを組み合わせて使い、両者の長所を利用することで、ファイルサイズやCPUの競合するニーズに対応できます。
Opusを使ったループやシークについて
Opusでは、シークやループ用のシークテーブルは不要ですが、その分、CPU負荷が高くなり、ディスクアクセスが増えます（ストリーミングの場合）。
これを念頭に、Opusの利用はシークやループのニーズが最小限または皆無のサウンドに制限すべきです。なお、ファイル冒頭のシークやループは軽度なので、このような余計なコストがありません。

**名無しさん＠お腹いっぱい。** · 2018/12/11(火) 14:20:15.26

Resource usage - リソースの消費 - OpusとVorbisの比較: [http://listening-test.coresv.net/results.htm]で見る限り、Opusコーデックの方がVorbisよりも、同程度のビットレートでの音質評価がやや高いようです。
同じファイルサイズで音質が高い方が、一見、有利なように思えますが、品質が多少なりにも高い裏には、Opusの方がWwise VorbisコーデックよりもCPU負荷が4倍から5倍も高いという現状があります。
とはいえ、何千ものダイアログラインや、長いSFXや、ループなしの単一ストリームミュージックなどを圧縮するには最適の選択です。
Opusとほかのコーデックのオーディオ品質の比較についてさらに詳しく知るには、 [https://opus-codec.org/comparison/]を参照してください。

**名無しさん＠お腹いっぱい。** · 2018/12/11(火) 14:22:01.23

OpusとOpusNX
https://www.audiokinetic.com/ja/library/edge/?source=Help&;id=glossary
Opus
音声と汎用オーディオの両方に最適化された、低レイテンシのオーディオコーデック。音質を損なうことなく他のコーデックより優れた圧縮率を発揮します。Opusコーデックのこのバージョンは公開仕様に基づくもので、すべてのプラットフォームで利用できる。

OpusNX
音声と汎用オーディオの両方に最適化された、低レイテンシのオーディオコーデック。音質を損なうことなく他のコーデックより優れた圧縮率を発揮します。このバージョンはNintendo Switchハードウェアでデコードされ、一般的なOpusソフトウェアデコーダとの互換性がない。

**名無しさん＠お腹いっぱい。** · 2018/12/12(水) 14:37:59.46

https://github.com/kode54/vgmstream/blob/master/README.md#vgmstream
A few extensions that vgmstream supports clash with common ones. Since players like foobar or Winamp don't react well to that, they may be renamed to make them playable through vgmstream.
.aac to .laac (tri-Ace games)
.ac3 to .lac3 (standard AC3)
.aif to .aiffl or .aifcl (standard Mac AIF)
.asf to .sng (EA games)
.flac to .lflac (standard FLAC)
.mp2 to .lmp2 (standard MP2)
.mp3 to .lmp3 (standard MP3)
.mp4 to .lmp4 (standard M4A)
.mpc to .lmpc (standard MPC)
.ogg to .logg (standard OGG)
.opus to .lopus (standard OPUS or Switch OPUS)
.stm to .lstm (Rockstar STM)
.wav to .lwav (standard WAV)
.wma to .lwma (standard WMA)
The main advantage to rename them is that vgmstream may use the file's internal loop info, or apply subtle fixes, but is also limited in some ways (like standard/player's tagging).

**名無しさん＠お腹いっぱい。** · 2018/12/15(土) 04:22:44.74

Youtube Music
アプリ版はAACでWeb版はOpusなんだな