Ликбез: Gapless

1. Истоки проблемы.

Хоть формат MP3 и не был первым форматом сжатия звука, основанном на частотном разложении сигнала и удалении избыточности за счет особенностей восприятия человеком звука - он стал самым популярным в мире благодаря ошеломляющему скачку в эффективности сжатия на момент своей разработки. Изначально он разрабатывался как формат для цифрового вещания, который предусматривал постоянный поток данных, при котором весь звуковой поток разбивается на фреймы по 1152 звуковых семплов, откуда в дальнейшем и появилась проблема с продолжительностью файлов отдельных треков в этом формате - они должны быть кратны продолжительности 1152 семплов. В большинстве случаев, естественно, соблюсти такое правило невозвожно, поэтому при кодировании в конец файла добавляется тишина, чтобы дополнить недостающее число семплов. То есть длина этой тишины колеблется от 1 до 1151 звуковых семпла.
Для справки. В формате аудио-CD используются иные по продолжительности фреймы, равные 588 семплов (75 FPS или 44100 Гц / 75 = 588). То есть продолжительность звучания треков в формате CD тоже ступенчата и дискретность равна 1/75 с. Как видим, из-за несоответствия продолжительности звуковых фреймов мы ВСЕГДА будем получать дополнительную тишину в конце MP3-трека для изданий с CD-формата. Для WEB-релизов нет никаких ограничений по продолжительности, но "угадать" с длиной трека кратной 1152 семплов - вероятность практически нулевая.

2. Развитие проблемы.

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

3. Решение проблемы.

Чтобы как-то решить проблему этих дополнительных фрагментов вначале и конце файла MP3 разработчики кодека LAME придумали оригинальное решение, они в метаданных заголовка MP3-файла добавляют информацию о продолжительности этих фрагментов в семплах, что позволяет плеерам, которые умеют считывать эту информацию, при воспроизведении просто удалять их, оставляя только "полезную" часть звукового файла. Эта технология получила название GAPLESS.

4. Подводные камни.

Вроде бы все хорошо, решение придумали, но возникла новая проблема, посмотрите пункт 2 и представьте, что весь файл MP3 - это большой фрейм, и на стыке с другим файлом MP3 - мы получим скачек амплитуды в месте их соединения, когда например концерт без пауз (Pink Floyd, Enigma и т.п.) и в месте стыка треков мы получим легкий щелчок, что не очень приятно. Поэтому разработчики придумали алгоритм коссфейда между треками GAPLESS, когда особым образом происходит наложение треков и интерполяция звука и этот скачек амплитуды становится незаметным. Эта технология называется TRUE GAPLESS. Ее использую популярные компьютерные плееры AIMP, Foobar и много других.

5. Заключение. Картинки и наглядные примеры (ссылки кликаемые)

Возьмем создадим оригинальный звуковой файл, где в одном канале будет звук квадратной формы, что позволит нам четко "увидеть" начало и конец звука, а во втором канале - белый шум. Теперь сохраним в MP3-формате и откроем в SoundForge, эта программа имеет простой декодер MP3, который не умеет считывать Gapless Info из метаданных, и вот что мы получим: появился дополнительный "кусок" в начале и в конце файла (выделено), также изменилась общая продолжительность, что и подтверждает всё рассказаное выше.
Теперь обратите еще внимание, что это не совсем "тишина", из-за особенностей алгоритма сжатия MP3 появилось так называемое "эхо", то есть "декодирование" сигнала появилось до начала собственно самого звука в начале файла и продолжалось после окончания звука в конце файла. Я неспроста сделал в одном канале белый шум, чтоб нагляднее продемонстрировать это явление. Вот поэтому и используется "хитрый" режим TRUE GAPLESS в современных плеерах, чтобы "объединять" эти эхо между смежными файлами MP3 при воспроизведении непрерывного альбома.

6. Другие форматы звука.

Во всех современных форматах сжатого звука проблема Gapless никуда не делась, и в каждом формате есть свое "решение":
- OGG Vorbis и OPUS - изначально добавили в метаданные длины начального и конечного фрагмента тишины, поэтому независимо от плеера или программы эти форматы всегда Gapless, то есть без лишних "пустот".
- AAC - тут все проблемы MP3 налицо, причем нет вообще стандарта для Gapless Info как у LAME MP3, из-за чего очень сложно добится Gapless воспроизведения. Например, в случае AAC кодирования с помощью встроенного кодера FFmpeg, количество семплов вначале может составлять 1024. С другой стороны, популярный кодировщик FDK-AAC обычно производит 2048 семплов в начале, хотя это количество может изменяться в зависимости от настроек кодировщика. Поэтому "угадать" начало реального звука в этом формате невозможно, только можно "на глаз", декодируя звуковой файл и примерно определять "начало".
- AC3 - как "проотец" формата MP3 также имеет "пустоту" вначале, но она уже заранее известна и прописывается в метаданных видео-контейнера для правильной синхронизации с видеорядом.
- ну и у остальных форматов сжатия плюс-минус похожие проблемы и они все по-разному решаются в современных форматах и приложениях, не хочется загромождать тему, это уже отдельный разговор.

Надеюсь Вам было интересно, будут еще новые статьи в дальнейшем. С уважением, Александр, MoyUspeh.

MoyUspeh, приветствую Вас Александр.
Вы прекрасно всё расписали по форматам Lossy, но на Ваши доводы есть опровержения от оф. источника. На скриншоте выделена нужная информация:
https://prnt.sc/PchgrkywWGIH
Хотелось бы услышать Ваше мнение. )

Jеssikа сказал(a):

MoyUspeh, приветствую Вас Александр. Вы прекрасно всё расписали по форматам Lossy, но на Ваши доводы есть опровержения от оф. источника. На скриншоте выделена нужная информация: https://prnt.sc/PchgrkywWGIH Хотелось бы услышать Ваше мнение. )

Впервые слышу, что статьи на ixbt - правда в последней инстанции. Доверять их анализу я бы посомневался, очень часто там выставляют статьи совершенно далекие от темы люди, лишь поверхностно вникнувшие в суть. И в данной ветке анализ и опровержение я не хочу делать, так как здесь тема о Gapless, а не о спектральном анализе дельта потерь сжатия. Даже по поверхностному анализу картинки видно, что это фейк, как может MP3 с включенным LowPass-фильтром иметь МЕНЬШУЮ дельта в области более 20000 Гц? Не задумались? По идее, если в общем спектре потери меньше, то в части спектра более 20000 Гц - они должны быть БОЛЬШЕ, а на картинке я этого не наблюдаю, я вижу "преимущество" по всем чатотам, что не укладывается в идею "заменим высокие частоты на более детальную проработку остального спектра". Как-то так :) Тут по картинке не особо видно "граничную" частоту частотного анализа, что вводит в заблуждение, то есть не видно, до какой частоты идет анализ, до 20000 Гц или до 22-24000. Поэтому нужно проводить отдельное исследование и показать наглядно, а для этого я позже создам ветку про LowPass-фильтрацию и эффективность PSY-анализа при сжатии MP3. На всё нужно время, не всё сразу.
p.s. По поводу той статьи с IXBT, там сравниваются "динозавры", LAME 3.88 и OGG-кодировщик, вышедшие в 2001 году, так, к слову.... очень много всего поменялось с того времени... Об этом я расскажу в другой своей статье. :) Ожидайте.