Как стать автором
Обновить

Комментарии 21

Пережать mp3 в opus

Скажи мне, что не понимаешь принципов пережатия, не говоря мне...

Нигде и никогда не видел нормальной информации, насколько звук перегнанный из 320к mp3 в opus 64k будет хуже, чем 64k полученные из оригинала. Конечно, приняв за условие что mp3 не битый.

Напомню, что половина поганости mp3 происходит из-за того, что раньше было распространено множество кодировщиков с просто бракованными алгоритмами. Один независимо от битрейта обрезал все частоты выше 16к Гц, другой вносил столько шумов, что фактически выход всегда был эквивалентен 16кб/с битрейта, независимо от размера файла и т.д.

Вопрос не только в "поганых кодировщиках" прошлого, но и в принципиальных различиях в работе психоакустических моделей MP3 и Opus. Насколько "интеллектуальнее" Opus справляется с уже "упрощенным" MP3 потоком? Не усиливает ли повторное квантование артефакты, внесенные MP3? Но это только из того, что знаю и слышал - глубоко не копал на практике.

Пережми и послушай сам. Если это музыка и ты не услышишь большую разницу то... возможно ты слушаешь через дешевые колонки из 1995.

64к будут погано звучать и там и там, тут ты прав. Если это уровень, к которому ты стремишься — не вопрос.

Завести 2-3 лишних аккаунта в гугле или мэйл.ру и 50 GB облака в кармане. Зачем так мучить себя пережатиями?

Тогда уж купить терабайт на Яндекс.Диске по цене чашки кофе в месяц и не мучить себя распределением файлов между разными аккаунтами, если мы про облачные хранилища :)

P.S. А музыка с битрейтом 64k - это, конечно, для очень непритязательного слуха или для очень плохого устройства воспроизведения...

Согласен. Музыку лучше жать (два канала) от 128 до 160k. Всё же 64k - это чисто для речи или моно.

У меня локальная коллекция вообще неcжата (FLAC'ов терабайта 2 давненько уже любовно собрано), но не буду утверждать, что я прямо такой аудиофил, что реально различу lossless и 320k, да и даже 192k... Просто если можно хранить без сжатия - зачем хранить со сжатием. Ну и, честно говоря, последние годы редко что-то из этой коллекции слушаю, стриминговые сервисы всё же гораздо удобнее...

У меня откуда-то 1 ТБ на мэйл.ру и бесплатно. Может, когда-то давно акция была... А насчёт кофе, чел же специально написал - не может. Может, он учитель или терапевт)

1Тб мэйл раздавал за участие в тестировании облака, когда оно только вышло. У меня такое же. И 250 на Яндексе в качестве извинения за то, что авто обновление ЯДиска однажды убило винду.

Откуда-то пахнуло тёплым ламповым 1996-м годом, когда лишний десяток мегабайт неиллюзорно напрягал...

Аналогично, сразу Lame с командной строкой вспомнил и первую пачку пережатых в mp3 Audio-CD.

Вижу 2 хороших варианта:

  1. Всегда оставлять звук в изначальном lossy-формате, не перекодировать.

  2. Не думая выбирать Opus, доверяя графику с их сайта, где он на всех битрейтах не хуже, чем... чем AAC-LC и HE-AACv1, судя по всему. К тому же ffmpeg к libopus даёт хороший интерфейс, а с доступом к лучшему энкодеру AAC от Apple есть сложности (может быть проще не через ffmpeg).

  3. На битрейтах ниже 100kbps выбирать xHE-AAC, если имеется его поддержка и не волнует его огороженность. На графике в предыдущем пункте профиля xHE-AAC точно нет, а на низких битрейтах он лучше Opus'а (на 128kbps Opus и разные AAC примерно равны).

---

aac_low ... Аудио приемлемо звучит с битовой частотой 128k.
aac_he ... Аудио приемлемо звучит с битовой частотой 64k.
aac_he_v2 ... Аудио приемлемо звучит с битовой частотой 32k.

128kbps у AAC-LC оценивается как весьма хорошее качество, а остальные профили этот уровень дают на тех же 128kbps, лишь подтягивая качество на низких "явно непрозрачных" битрейтах и позволяя забраться без ушных кровотечений ещё пониже:

В случае с HE-AACv1 это можно так объяснить: HE-AACv1 = AAC-LC + Spectral Band Replication, который восстанавливает высокие частоты, а их выкидыванием энкодер занимается на низких битрейтах.

aac_he (4): High Efficiency AAC (HE-AAC) - Низкая совместимость

Но есть обратная совместимость с AAC-LC - информация об SBR проигнорируется и файл проиграется как обычный AAC-LC, без высоких частот.

А HE-AACv2 = AAC-LC + SBR + Parametric Stereo будет играться как моно AAC-LC. Тестовые файлы (первый HE-AACv1, второй HE-AACv2).

И раз я начал говорить про самый новый профиль: USAC в xHE-AAC не опирается на AAC-LC, обратной совместимости нет.

Размеры больше 20 мс интересны только при достаточно низких битовых частотах.

Но почему? Используем Opus не для реального времени => задержка декодирования не важна => выкручиваем на максимум ради качества, не углубляясь в величину выигрыша (5%?.. 1%?..).

 не углубляясь в величину выигрыша (5%?.. 1%?..).

А может быть 0.00...01%, при этом есть риск нарваться на декодер, не умеющий нестандартное значение.

Оно не дефолтное, но стандартное.

Ответ на мой вопрос в том, что качество может быть хуже, но так говорят про OPUS в файлах на любых битрейтах.

For file encoding, using a frame size larger than 20 ms will usually result in worse quality for the same bitrate because it constrains the encoder in the decisions it can make - https://wiki.xiph.org/OpusFAQ#What_frame_size_should_I_use?

Спецификация: режимы Hybrid и CELT-only не поддерживают размеры выше 20 мс - https://datatracker.ietf.org/doc/html/rfc6716#page-15

О режимах: OPUS - это 2 кодека в одном, SILK для голоса на битрейтах около 8-16 kbps и CELT для музыки. И их одновременный гибрид (SILK для <8 кГц, CELT для >8 кГц) для качественного голоса (16-64 kbps).

На гитхабе xiph/opus говорят, что framing overhead ощутим в RTP, но не в файлах и "If your application is encoding low bitrate music to file, then the best frame size to use is 20 ms, not 60 ms, not 120 ms. Using larger frame sizes just concatenates 20 ms frames, but it prevents the encoder from making optimal decisions".

Для сжатия материала пользуюсь Shutter Encoder. Под капотом там конечно ffmpeg.

Из полезного:

В DaVinci на винде можно выводить только в DNx, который Мак никак не читает. Поэтому дополнительно перегоняю в ProRes, чтобы кому-нибудь отдать.

Часто приходится перекладывать из контейнера в контейнер, потому что исходники открываются неправильно. Ну и эта программа может выполнять эту функцию.

Иногда требуется обрезать видео, но не хочется лишний раз перекодировать из 264 в 264. Это ухудшает качество, так что можно обрезать без перекодирования в названной программе.

Набор функций №1
Набор функций №1
Набор функций №2
Набор функций №2

Я для себя нашел опытным путем следующее решение: все что действительно стоящее - в FLAC в "холодном хранилище" на внешнем HDD, а все что "ношу с собой" - в Nextcloud, и тоже в Opus, правда 96k. Ни я, ни один из знакомых разницы с FLAC не слышит (на KOSS Porta Pro). Но это если жать из Lossless. Пережимать MP3 в Opus, да еще и 48k - это... даже не знаю чем и на чем слушать чтобы назвать "приемлемым".

Для сжатия аудио-файлов лучшим вариантом является использование кодека libopus в режиме vbr on с битовой частотой 48k

Когда пишут про частоту, обычно это относится к частоте дискретизации (sample rate).

Когда пишут о потоке данных (не обязательно сжатых), обычно используют термин "битрейт", или data rate/bit rate.

В статье сказано: "Какой профиль AAC выбрать? Выбирайте HE-AACv2.". На самом деле совет очень такой себе. Подходит только для сверх низких битрейтов наподобие 15-25 kbps (собственно для них v2 и был разработан). Потому что если при воспроизведении v1 синтезируются недостающие частоты, то при v2 к этому добавляется ещё и стерео панорама. То есть файл кодируется в моно, с добавлением небольшой информации о каналах, а потом декодер пытается всю картину восстановить. Всё это звучит абсолютно похабно, и на более высоких частотах применение профиля v2 совершенно неоправданно. То же самое касается v1. При битрейтах выше 64-80 лучше использовать нормальный честный lc профиль.

Проще bat команду прописать на 3 строки. Зачем так заморачиваться?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации