Обновить

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

Как то можно проверить, что реализация достаточно хороша? FLAC lossless насколько я помню, значит ли это что одинаковые преобразования должны давать одинаковые результаты и можно сравнить результаты с другими энкодерами?

UPD: лайк за статью, нравится читать такое

Добрый день, спасибо за комментарий
Вы правы FLAC это lossless, поэтому правильная реализация должна восстанавливать аудиоданные бит-в-бит. Получается если взять исходный WAV-файл, закодировать его в FLAC go-энкодером, а потом декодировать - результат должен быть полностью идентичен оригиналу

Сейчас планирую добавить побайтовое сравнение:

original.wav -> мой FLAC -> decoded.wav -> cmp original.wav decoded.wav

И проверку через flac --test и совместимость с другими плеерами (VLC, Audacity и т.д.).

Так что да — в ближайшее время сделаю полноценную валидацию и добавлю в Readme
Спасибо за напоминание

Автора не критикую, но всё же выражу скепсис - потратить время на то, чтобы написать свой урезанный и не факт, что функциональный вариант конвертера, ради экономии 75 мб (тут не очень понятно, о чём речь, видимо о каком-то из static build)

Просто в alpine он установленный весит 600 кб, да и с зависимостями там мегабай 25-30 наберётся

Никакого усложнения CI при этом не видно

В общем, боли не очень понятны, решение мало что даёт, но отбирает поддерживаемое, обновляемое, проверенное решение, заменяя его достаточно спорным

Добрый день, спасибо за комментарий, у меня было 2 цели
1. у меня есть несколько утилит по звуку, и хотелось замкнуть зависимости на свой репозиторий
2. академический интерес - написать свой конвертер, в процессе выяснилось, что для FLAC энкодера на го нет - было интересно свой попробовать написать

Оба пункта волне легитимны и вы имеете на это полное право.

Скепсис именно к формулировке болей

"Бенчмарки": так а почему в них нет FFmpeg? :)

Добрый день, ух)
По правде сказать - специально не сравнивал - разные задачи. FFmpeg быстрее, но тянет зависимости. Тут цель была - один бинарник, скачал и работает. Бенчмарки показывают что хватает с запасом.

Я не был знаком со структурой FLAC, однако я вижу что вычисление CRC занимает значительную часть кода.
Не пробовали сами реализовать подсчёт CRC? Его можно подсчитывать последовательно или табличным методом. Вплоть до того, что для каждого байта одной ассемблерной инструкцией. Учитывая применение для каждого чанка, в результате малейшей оптимизации, ускорение будет удивительным безо всякого распараллеливания.

Добрый день, спасибо за коммент,
Табличный метод уже используется - lookup table 256 байт для CRC-8 и CRC-16, один XOR + lookup на байт:
crc8 = crc8Table[crc8 ^ byteVal]
crc16 = (crc16 << 8) ^ crc16Table[(crc16>>8) ^ byteVal]

По профайлеру основное время в Rice coding, а не в CRC. Но если найдутся кейсы где CRC станет узким местом - попробую slicing-by-4.

Ffmpeg можно собрать самому без зависимостей, которые вам не нужны. Скажем указать только нужные вам кодеки. Это делается при помощи configure перед сборкой. Я думаю раз в 10 можно объем зависимостей уменьшить и бонусом будет более новая версия ffmpeg.

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

Публикации