mp3圧縮でどこまで容量を下げられるか？ [電気音響]
オーディオのデータは，ムダに高いビットレートとかハイビット分解能にしない限りは大きくはならないので，昨今の環境では，ケチケチとデータ量を削る必要も無いはずですが。。。
何分SSブログの「ファイル」の前近代的な仕様により，音声や動画の容量は5MBまでとなっています。これで動画のアップロードはまず無理ですので，YouTubeほか動画配信サービスは規格もサービスも大幅に拡充されたものがありますので，それらを埋め込めば済みますので，SSブログ純正?の5MB以内の動画を使う方はまずいないのではないかと思います。
音声は動画のオマケのようなものですから，YouTubeなどの動画を埋め込めば済みますが，音声録音の場合でも何かの画像を埋め込む手間が掛かります。むろん動画撮影をしていればそれを用いる事になります。ただ，それをウリにすれば別ですが，素人の演奏動画の鑑賞は正直シンドイので，画像などを埋め込む事になり，編集の手間がかさみます。
そういう意味で，音声だけを上げる割り切りでSSブログの5MB枠を使うとすると，動画ほどでは無いにしても演奏時間の制限が厳しくなります。
今更ながらですが，どこまで下げると，音質劣化が生じて来るのでしょうか？
余りやりがいのある作業でもないですが，一応やってみます。
なお，デジタル・スペックだけをムダに上げても意味がありませんので，元の録音スペックは普通のCDと同じ16ビット44.1kHサンプリングです。昨年上げた音源「粉屋の踊り」を使います。演奏時間は3:12でした。
mp3に変換する際のビットレートをもとの（標準の）128kbpsから，半分づつ下げて行きます。
最低ビットレートまで下げていますが，その際元データのサンプリングレートもアプリの指示に従って下げています(16kbpsでは11kHz，8kbpsで8kHz)。ファイル容量はほぼビットレートに比例して低下します。
流石に，ビットレート32kbps以下では酷い音質です。64kbpsでも音がよれている様なところがあります。5MBの制限を満たして演奏時間を拡大するには，128kbpsから64kbpsの間の，112kbps，96kbps，80kbpsあたりを使うのが実際的ではないかと思います。
ただ以前から気になっているのですが，LAMEは音質があまり良く無い様な気がしていますが，ビットレートだけの問題なのかどうか，同条件で比較しにくいので何とも言えません。
5GだとかWiFi6の[Gbps]の時代に，[kbps]を試すなど，ケチな話ではありますが。
音声は動画のオマケのようなものですから，YouTubeなどの動画を埋め込めば済みますが，音声録音の場合でも何かの画像を埋め込む手間が掛かります。むろん動画撮影をしていればそれを用いる事になります。ただ，それをウリにすれば別ですが，素人の演奏動画の鑑賞は正直シンドイので，画像などを埋め込む事になり，編集の手間がかさみます。
そういう意味で，音声だけを上げる割り切りでSSブログの5MB枠を使うとすると，動画ほどでは無いにしても演奏時間の制限が厳しくなります。
◆
今更ながらですが，どこまで下げると，音質劣化が生じて来るのでしょうか？
余りやりがいのある作業でもないですが，一応やってみます。
なお，デジタル・スペックだけをムダに上げても意味がありませんので，元の録音スペックは普通のCDと同じ16ビット44.1kHサンプリングです。昨年上げた音源「粉屋の踊り」を使います。演奏時間は3:12でした。
mp3に変換する際のビットレートをもとの（標準の）128kbpsから，半分づつ下げて行きます。
| 規格/ビットレート | ファイル容量[MB] | 音源 |
| WAV/44.1kHz16bit | 33.9 | アップロード規格外 |
| mp3/256kbps | 6.1 | アップロード不能 |
| mp3/128kbps | 3.1* | 粉屋の踊り128kbps |
| mp3/64kbps | 1.5 | 粉屋の踊り64kbps |
| mp3/32kbps | 0.768 | 粉屋の踊り32kbps |
| mp3/16kbps | 0.384 | 粉屋の踊り16kbps |
| mp3/8kbps | 0.192 | 粉屋の踊り8kbps |
最低ビットレートまで下げていますが，その際元データのサンプリングレートもアプリの指示に従って下げています(16kbpsでは11kHz，8kbpsで8kHz)。ファイル容量はほぼビットレートに比例して低下します。
流石に，ビットレート32kbps以下では酷い音質です。64kbpsでも音がよれている様なところがあります。5MBの制限を満たして演奏時間を拡大するには，128kbpsから64kbpsの間の，112kbps，96kbps，80kbpsあたりを使うのが実際的ではないかと思います。
ただ以前から気になっているのですが，LAMEは音質があまり良く無い様な気がしていますが，ビットレートだけの問題なのかどうか，同条件で比較しにくいので何とも言えません。
5GだとかWiFi6の[Gbps]の時代に，[kbps]を試すなど，ケチな話ではありますが。
エンコードする際ビットレートはどれくらいに設定すべき？
いつもの脱線で済みません！ MP4等の動画に、BPPがあって、
1. BPP を決め 2. fps を決め 3. 動画の幅と動画の高さを指定すれば
＝ 映像ビットレートが求められます。逆算してBPPを求めることも出来ます。
4. 加えて、音声ビットレートと 5. 再生時間を決めると
＝ ファイルサイズを求めます。
以上をWebでJavaScriptによって自動計算するページを作ったことがあります。 何とか、ファイルサイズを指定して、MP3音源の各緒元が決められる方程式を作れば良いですね。
by Ujiki.oO --> BPP (Bits Per Pixel) (2022-04-24 11:11)
1. 拡張子の存在は忘れても良い
mpegだからmp3でないといけないなんてことは嘘！
jpegだからjpgでないといけないなんてことは嘘！
HTML5から、audioタグやvideoタグが定義されたことにより、天下のFLASHプレイヤーは駆逐されました。 HTML5のautoタグ内で指定するSOURCEタグは異なるエンコード音源毎に定義すると言うのは誤解！ SOURCEタグは、例えばMP3で、複数のビットレート毎に定義する。 SOURCEタグのSRC＝には、拡張子は特に無用！ 拡張子に囚われてはいけない。 拡張子では無くて、SOURCEタグのtype=で決まる！ つまりSRC＝でxxxx.jpgと指定しても、type=audio/mpeg と、指定すれば、xxxx.jpgはMP3だと解釈する。 誰が解釈するかは、インターネットに接続し、訪問してきた、端末（またはブラウザー）が解釈する。 だから、GoogleドライブやDropboxから生成するURLをSRC＝に指定できた。
2.大馬鹿なWEBサーバーがある。
折角の自由度のあるHTML5なのに、MSのOS的、拡張子に囚われて、typeをWEBサーバーがオーバーライドしているおおー馬鹿サーバーがある。きっと無料ブログサーバーなどでは、無用なtypeの初期値を訪問者のブラウザーに送りつけているかも知れない。
3.大馬鹿ばかばかな「音源プレイヤー」の存在
URLの拡張子で規制するのは大馬鹿！ 拡張子で制御を拒否する音源プレイヤーはクズ
打開策１：
320ｘ320の２値の静止画を埋め込んで、音楽ソースの長さに動画を作成し、その無音の動画に限界突破した高尚な音源を埋め込む。後はユーチューブのEMBEDコードをブログに埋め込む。
打開策２：
限界突破した高尚な音源をGoogleドライブにアップし、拡張子の無いURLを、独自MP3プレイヤーに埋め込む。（きっとSSブログの音源再生プレイヤーが拡張子に囚われているのですよね？）
by Ujiki.oO --> <audio>: 埋め込み音声要素 - HTML: HyperText Markup Language | MDN (2022-04-24 13:33)
Ujiki.oOさん，
画像のjpeg，動画のmpeg，そして音声のmp3などは，原理的には離散余弦変換などの直交変換をして高周波数領域のカットによるデータ量の削減が主でしょう。いずれも非可逆圧縮動作であり，画像のjpegなどは元データの性質により変換後のデータ量の差が顕著です。すなわち，細かい（高周波数成分を含む）画像の圧縮比は少なく，のっぺり画像だと大幅に圧縮できます。ただそれらはいずれもカメラ画像など（自然な）画像に限る必要があり，線画やイラストなどはGIFやPNGなどの可逆圧縮にすべきですが，圧縮比の大きさの魅力からか，何でもかんでもjpegを使う風潮が感じられます。
動画の場合，フレーム間圧縮に調整が入れられるのかどうか知りませんが，やはりビットレートが変えられるのでしたら，一枚一枚の画像そのものとフレーム間の間引きによるデータの劣化はあるのでしょう。
音声の場合は，こちらでデモした様にデータ量と音質とはトレードオフです。どのデータの非可逆圧縮に関しても共通原理でしょう。
さて，拡張子に関する点は，プログラマーのリテラシーに関する問題でしょう。これを3文字にすべきというのは，MS-DOSのファイル形式を亡霊の様に引きずるWindows（しか知らない）プログラマの問題でしょう。きっとMS-DOSからWindowsに移行した時に経験したとか，そういうご先輩に指導を受けたとかではないのでしょうか？旧来の"XXXXXXXX.YYY"のファイル名にしておけば間違いない。しかもそのYYYはファイル属性を示しているのだと。そんなバカなものでやられたらインチキし放題だと皆さん分かった上で？？？当方はとうの昔にプログラミングは止めていますので，偉そうなことは言えませんが。何分，プログラミングを止めた当方は，アート方面に走っていますので，特に演奏に特化したい時は面倒なこと嫌いです。
by Enrique (2022-04-25 01:35)
＞ GIFやPNGなどの可逆圧縮にすべき
おっしゃる通りだと存じます。 仏蘭西人が開発した PhotoFiltre を利用して、画像を保存する際に、各ファイル種毎のパラメーターを選択するだけでも勉強になります。 Win11でも何も問題無く利用できています。 PhotoFiltre で芸術的に画像を変換（色付け）し、flickr.comにアップしている方々もおられますね。 自分の勉強のために PhotoFiltre を推奨したい。
＞ 特に演奏に特化したい
Googleが監修したタブレットを、So-netから購入した昔、当該タブレットの利用者同士が喧嘩していました。 ある方が「ハイレゾ音源を聞けるから素晴らしい！」と絶賛すると、他の方が「それはハイレゾファイルを扱えたとは言えない！」と反論する。 「おもろいなあ～」と思うだけです。 重要な事は、ハイレゾ音源に対しても再生できず無音再生（バチバチ音）よりも、再生できるハードウェアー（またはシステムソフト）であることが、ユーザーにとって親切だと言うことです。
ハイレゾ音源データーをファイルとして所有していても、ハイレゾ再生は困難です。 タモリ倶楽部の放送で「マイ電柱」の回があり録画していますけど（笑）、マイ電柱の工事内容から、見積金額から、そして高級なアンプと高級なスピーカーから音楽を聴くと言う内容でした。アース棒を何本打つかとか、ブレーカーのネジの材質までこだわらないと、ノイズに悩まされるのだそうです。 TV放送自体がハイレゾじゃないし、我が家のTV自体がハイレゾを再生しない。 「口に指を咥える」しかない放送です。 で、タモリはゲストに向かって「違いが判る？」と漏らします。
私は、たかが４万円クラスではあるもののボーズのヘッドセットを購入した際に、「違いが判らなかった」記憶があり、「そうなんだ、自分の肉体の耳がハイレゾ仕様になってない」と、諦めました。（笑）
芸術を追及されている Enrique さんには、ハイレゾ音源の配信をお願い致します！
Enrique さんが、１００人の高校生の前で、ハイレゾ音源を再生している Enrique さんのHPを、白板に投影しながら、「みなさんの携帯電話で訪問して聞いて、感想を提出してください」と宿題を出したとします。 １００人が全員、様々な自分の端末で「聞けたのか？聞けなかったのか？どうなんだい？・・・・聞け～～～～～～ナイっ！」
Enrique さんは聞けなかった高校生の端末の機種を調べて、その端末が聞ける仕様に、ハイレゾからスペックを落とした音源に変換して、そのスペックダウンした音源をアップロードして、別ページを公開し「聞けなかった生徒は、新しいページを用意したから、そっちで聞いてね」と緊急グループメッセージする。
どうだ？「聞けたのか？聞けなかったのか？どうなんだっ？・・・・聞け～～～～～～ナイっ！」
YouTubeの優れているところは、受信専用のアプリを無数と言える端末毎にせっせと開発し、端末メーカーに提供している点です。 おもちゃの無線機の様に、YouTube専用の送信受信システムを独自に開発し提供している点です。 だから「４K動画のアップ可能！」を実現しています。 仮に、iPhone3でYouTubeを再生し、４K動画を選んだなら、YouTube側の、いわゆるゲーミングPCが何十台も並んだ並列コンピューター群が、スーパーコンピューターと同じように、高速処理して、iPhone3でも再生できるスペックダウンした動画データーを瞬時に作成しながらリアルタイム提供する。 CM動画を再生中に変換はバッファ分は進む。 １年後に、iPhone3での接続が無ければ、変換後のキャッシュファイルはとっととGoogleサーバーから削除する。
Yahoo!が開発した現在のflickrは素敵で、あらゆるサイズダウンした画像を自動的に生成し、公開URLとして利用できる。
さて、喧嘩したハイレゾ音源再生の当人達はナンセンスです。 端末のスピーカーが小さ過ぎて「チャチイ」のです。 ブルーツースで飛ばそうが、有線の金コネクターを挿そうが、最高級の高額スピーカーに接続しても、コネクターを挿した段階で、ソースの音源の波形を汚している。
HTML5のAUDIOタグのSOURCEタグは、多段で定義可能です！
＜audio＞
＜source src=ハイレゾ音源のURL ＞
＜source src=第壱段階のスペックダウン変換した音源のURL ＞
＜source src=第弐段階のよりスペックダウン変換した音源のURL ＞
＜source src=第参段階のもっとスペックダウン変換した音源のURL ＞
＜source src=もうどんなハードでも聞けるだけに特化したスペックダウン変換した音源のURL ＞
＜／audio＞
ああ～、FLASHとの共存を目指しただけの Ujiki.oO製のMP3プレイヤーは、この対応はしていません。
by Ujiki.oO --> PhotoFiltre 28ヶ国言語メニュー簡単切り替え機能搭載の無料画像編集ソフトのインストーラーの配布はここだけです (2022-04-25 11:44)
Ujiki.oOさん，
ローレゾの限界を試している当方としましては，ハイレゾの必要性が全く感じられませんので，試すつもりはありません。
ハイレゾなるもの，単にデジタル規格の入れ物にすぎません。まず，よほど良いもので録音して，余程高級な再生系でないと全く違いの分からない，意味の無いものだというのが当方の見解です。
高精細な画像や，4K動画，8K動画は美しいですが，少し離れて見れば，フルハイビジョン画像と大差ありません。音源を高精細動画に例えて言えば，少し離れて，それらの差が分からない距離で見ているようなものです。画像は拡大したり近寄って細部を確かめられますが，音声では再生を遅くして高周波を低音にして聴くなどというバカな事はしませんね。
マイ電柱の話は当方もオーディオ誌か何かで見ましたが，電気工学を専攻した者の見解としましては，それだけ電源に拘るならば，大型の蓄電池で直接直流を使うのが最も良いですし，交流を使うにしても三相から直接全波整流すれば，整流回路はずっとシンプルで良い電源になります（電力会社は許さないでしょうが）。
https://classical-guitar.blog.ss-blog.jp/2016-12-14
わざわざ，マイ電柱で単相変圧器を独占して100Vを使ってまたまたアンプ側でごちゃごちゃやる事が，格段に素晴らしいとは考えられません。凝るならば原理的により効果的な方でやりたいですね。
by Enrique (2022-04-25 14:17)