FLAC 1.5 с долгожданной многопоточностью

Можно качать?

Интересно, кто по сжатию победит - flac или какой-нибудь архиватор общего назначения?

Наверное имелся в виду не архиватор, а компрессор.

Я сравнивал, обычно flac побеждает, даже у LZMA2 (xz, 7z) с максимальным сжатием и большим словарём.

Не сравнивал только с совсем-совсем медленными штуками вроде PAQ.

Ну, может и компрессор:)

Интересно, за счёт чего flac выигрывает? В случае mp3 понятно, там отбрасывается часть данных. А flac чем берёт?

долгожданной

А можно, пожалуйста, ссылки на треды или сообщения, в которых кто-нибудь испытывал невыносимые душевные страдания от отсутствия многопоточности во flac?

За счёт более специализированных под аудио алгоритмов. Понятно, что если жать белый шум, то флак будет менее эффективен, чем компрессоры общего назначения, но обычно звук имеет некоторые особенности: например, в двух каналах звук будет, как правило, не полностью независим, а имеет нечто общее, также обычно каждый следующий сэмпл не находится на противоположном конце от предыдущего, поэтому можно более эффективно применять более конкретные алгоритмы, подходящие именно для таких данных, а не для любых. Поток бьётся на блоки определённого количества сэмплов каждый, затем делается аппроксимация, обычно подгонкой простого полинома к сигналу, наиболее близкого, а затем для разницы между реальным сигналом и полученным из подогнанной простой функции уже используется энтропийное кодирование (коды Голомба вроде бы, надо смотреть). Компрессоры общего назначения работают несколько иначе (тут надо каждый конкретный смотреть, ну или совсем вкратце — сжатие со словарём).

Это, если что, довольно сильное упрощение — например, не всегда используется полином, может и LPC, есть и другие фичи, есть сикпоинты, и прочее всякое, что влияет как положительно, так и отрицательно на степень сжатия. Но какое-то общее представление, почему так, надеюсь, даёт.

В гугле забанили?

Да и количество всяких костыльных и не очень скриптов, чтобы хоть как-то это дело загнать в многопоток (например, кодировать N дорожек за раз, а не последовательно), измеряемое сотнями, если не тысячами, как бы намекает.

P.S. Долгожданность не предполагает обязательных невыносимых душевных страданий, не обязательно доводить всё до абсурда.

Наверное имелся в виду не архиватор, а компрессор.

А чем отличается архиватор от компрессора? И почему сабж называют аудиокодек?

Разве: wav1 -> flac -> wav2 не дают полностью одинаковый wav?

А чем отличается архиватор от компрессора?

Архиватор позволяет собрать много файлов в один. Например, для передачи по сети одним скачиванием вместо тысячи. Пример архиватора — tar.

Компрессор позволяет уменьшить объём, занимаемый данными, путём использования различного кодирования. Примеры компрессоров: gzip (gz, алгоритм DEFLATE), xz (алгоритм LZMA2), Zstandard (zstd), bzip2 (bz2).

Комбайн aka архиватор-компрессор (иногда также говорят гибрид в контексте) осуществляет и архивацию и компрессию, имеет специальный формат файла. Примеры комбайнов: zip, rar, 7zip.

И почему сабж называют аудиокодек?

Потому что он предназначен для кодирования аудио, подходит для непосредственно прослушивания, в том числе стриминга (то есть, можно декодировать, не имея полного файла, а получая кусочками), имеет сикпоинты, позволяющие проигрывание с произвольного места без декодирования всего потока, и т.д. и т.п.

Разве: wav1 -> flac -> wav2 не дают полностью одинаковый wav?

Дают. Хотя не всегда — теги могут потеряться в теории. Но PCM, то есть непосредственно аудиоданные, точно будут одинаковыми, это да.

Это насколько нужно быть заброшенным проектом, чтобы многопоточность только в 2025 году реализовать

А можно, пожалуйста, ссылки на треды или сообщения, в которых кто-нибудь испытывал невыносимые душевные страдания от отсутствия многопоточности во flac?

Это самая нелепая предъява, которую я слышал за последнее время.

Утилиту сделали качественно быстрее без всяких побочных эффектов – он недоволен.

— Глянь-ка, —
Толкует
Досужий народ,
Дедушка
Едет,
А мальчик
Идет!

Заброшенность тут ни при чём. И так весь мир юзает именно флак.

А так в gzip до сих пор нет, например, и ничего, все пользуются. В lame (mp3) тоже вроде нет.

И свинья и 7zip есть для мультипоточного сжатия gzip.

Сейчас не 2005 год, чтобы весь мир помнил о flac, имея свободный эпловский ALAC, удобный для яблок, завоевавших музыкальный мир

теперь умеют создавать новый файл при изменении метаданных, вместо перезаписи существующего.

Надеюсь, что это опция.

И свинья и 7zip есть для мультипоточного сжатия gzip.

Ну для FLAC тоже костыли сторонние были.

Сейчас не 2005 год, чтобы весь мир помнил о flac, имея свободный эпловский ALAC, удобный для яблок, завоевавших музыкальный мир

Ну вот…

Народ, кто знает, Фейри для монитора безопасен? Простой влажной салфеткой весь этот жир не удалить.

Спасибо за ликбез!

Естественно. «Умеют создавать», а не «создают» же :)

Опция -o.

И так весь мир юзает именно флак.

Ну вот не надо, большинство используют mp3 или aac и им совершенно плевать что они не 100% точные.

В rar-е, помню, было какое-то «мультимедиа-сжатие». Интерсно, есть ли реальные преимущества…

большинство используют mp3 или aac

Позволю себе в этом усомниться. Лет 15 назад это было бы однозначно правдой. Сегодня же я не уверен. Хорошей статистики у меня нет, впрочем.

без всяких побочных эффектов

Неужели степень сжатия не пострадала, пусть даже на 0.5%?

Неужели степень сжатия не пострадала, пусть даже на 0.5%?

Фиг знает, проверять надо. Будем надеяться, что нет. Он ведь по блокам кодирует, а не весь файл целиком, это необходимо как минимум для того, чтобы было seekable и streamable. А раз по блокам всё равно, то по идее можно эти блоки вполне себе параллельно жать, раз уж они независимы друг от друга. Но это теоретизирование, надо бы именно протестировать.

Но вообще 0.5% (т.е. 0.995 сжатие получится, если пережать в один поток) это много, это ты прям размахнулся. Если степень сжатия всё же пострадала, то скорее всего значительно меньше.

А что, есть ширпотребные аудио/видео сайты, которые по умолчанию отдают flac?

Но вообще 0.5% (т.е. 0.995 сжатие получится, если пережать в один поток) это много, это ты прям размахнулся

Эм, нет.

А что, есть ширпотребные аудио/видео сайты, которые по умолчанию отдают flac?

Bandcamp, Qobuz, Tidal, Deezer.

Ну и торренты, конечно, в основном на flac сосредоточены нынче. MP3 есть, но уже по остаточному принципу скорее. Даже на рутрекерах, не говоря уже о чисто музыкальных.

С видео, конечно, нет — там юзается opus и aac, как правило. На самом популярном ютубе, естественно, именно они, в самом высоком качестве (он там как-то хитро выбирает, в том числе в зависимости от выбранного разрешения видео зачем-то), если не ошибаюсь, Opus. Флак всё же скорее для музыки популярен, нежели для всего остального.

Bandcamp, Qobuz, Tidal, Deezer

+ Яндекс

Я скомпилял и проверил. Как я выше и предполагал — не пострадала.

Размер файла идентичен байт в байт даже при использовании -8ep версией 1.4.3 и -8ep -j 8 версией 1.5.0.

% time LD_LIBRARY_PATH=. ./flac -8ep -j 8 "01. Krystl-Ah.wav" -o 1.5.0.flac

flac 1.5.0
Copyright (C) 2000-2009  Josh Coalson, 2011-2025  Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

01. Krystl-Ah.wav: wrote 53920698 bytes, ratio=0.666
LD_LIBRARY_PATH=. ./flac -8ep -j 8 "01. Krystl-Ah.wav" -o 1.5.0.flac  30.53s user 0.06s system 794% cpu 3.849 total

% time flac -8ep "01. Krystl-Ah.wav" -o 1.4.3.flac

flac 1.4.3
Copyright (C) 2000-2009  Josh Coalson, 2011-2023  Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

01. Krystl-Ah.wav: wrote 53920698 bytes, ratio=0.666
flac -8ep "01. Krystl-Ah.wav" -o 1.4.3.flac  25.87s user 0.06s system 99% cpu 26.039 total

% ls -l *.flac
-rw------- 1 user user 53920698 Feb 12 09:45 1.4.3.flac
-rw------- 1 user user 53920698 Feb 12 09:45 1.5.0.flac

И на всякий случай, чтоб убедиться, что там даже пары байт разницы нет, скрытых за паддингом:

% metaflac --dont-use-padding --remove --block-type=PADDING *.flac
% ls -l *.flac                                                    
-rw------- 1 user user 53912502 Feb 12 09:55 1.4.3.flac
-rw------- 1 user user 53912502 Feb 12 09:55 1.5.0.flac

без потерь FLAC

Не знал, что он без потерь. Думал тоже вырезает частоты.

Что-то я эти четыре названия первый раз слышу, и по-моему музыку большинство слушают на всё тех же видеосайтах. А кто не на них - всякие яндекс-музыки и подобное платные, там вроде тоже пожатое (вот нашёл новость - полгода назад сделали возможность lossless).

большинство слушают на всё тех же видеосайтах

Я только когда сомневаюсь, качать что-то с рутрекера или нет.

Я испытывал.

На самом деле metaflac очень медленный при --add-replay-gain, возможно теперь будет на равне или быстрее rsgain

Но вот так, чтобы ждать, то вообще не ждал.

Настолько сильно это задолбало, что сделали реализацию компрессора на CUDA. Сжимает как из пушки, только данные успевай подавать.

Только вот по результатам не сравнивал.

Что-то я эти четыре названия первый раз слышу

O_o

и по-моему музыку большинство слушают на всё тех же видеосайтах

Нет конечно.

кто не на них - всякие яндекс-музыки и подобное платные, там вроде тоже пожатое (вот нашёл новость - полгода назад сделали возможность lossless)

Qobuz, Tidal и Deezer — это и есть вроде яндекс-музыки, только более популярное. Яндекс несколько отстаёт, там лосслесс только недавно появился. Но на то она и яндекс.музыка — далеко не основно сервис местячковой компании, мало кому в остальном мире интересной, выезжающий во многом из-за того, что бандлом к остальным фичам яндекс.плюс даётся. Ну и на популярности Алисы в России, конечно.

Bandcamp немного выделяется — там не стриминг по подписке, а покупка музыки. Навсегда, с возможностью как слушать в виде стриминга, так и скачать во flac (по умолчанию, другие форматы тоже доступны). Без подписок, каждый релиз отдельно. Это самый популярный и чуть ли не единственный в мире магазин музыки онлайн.

К сожалению, относительно недавно Bandcamp был приобретён компанией Epic (это та, что игры делает, Unrieal Engine разрабатывает, Epic Store держит). Пока это особо ни каким последствиям не привело, но и на гитхабе последствия покупки мелкомягкими были не сразу заметны. Пока ещё там весьма по-божестки, только 10% себе забирают, 90% — артисту. Как и было. Что будет дальше, будет ли цензура, будут ли ухудшения в плане распределения финансов — время покажет.

Ну то metaflac, а речь-то про кодирование. Там ждать надо, если хочешь максимальное сжатие.

Вот, кстати, провёл замеры (однопоточный 1.4.3 в сравнение чо-то не включил, но там 26 секунд, короче):

Benchmark 1: LD_LIBRARY_PATH=. ./flac -8ep -j 4 01.wav -o result.flac
  Time (mean ± σ):      6.830 s ±  0.014 s    [User: 27.115 s, System: 0.071 s]
  Range (min … max):    6.814 s …  6.853 s    10 runs
 
Benchmark 2: LD_LIBRARY_PATH=. ./flac -8ep -j 6 01.wav -o result.flac
  Time (mean ± σ):      4.786 s ±  0.005 s    [User: 28.346 s, System: 0.229 s]
  Range (min … max):    4.776 s …  4.793 s    10 runs
 
Benchmark 3: LD_LIBRARY_PATH=. ./flac -8ep -j 8 01.wav -o result.flac
  Time (mean ± σ):      3.937 s ±  0.096 s    [User: 31.226 s, System: 0.058 s]
  Range (min … max):    3.867 s …  4.136 s    10 runs
 
Benchmark 4: LD_LIBRARY_PATH=. ./flac -8ep -j 10 01.wav -o result.flac
  Time (mean ± σ):      3.842 s ±  0.013 s    [User: 37.599 s, System: 0.068 s]
  Range (min … max):    3.817 s …  3.861 s    10 runs
 
Benchmark 5: LD_LIBRARY_PATH=. ./flac -8ep -j 12 01.wav -o result.flac
  Time (mean ± σ):      3.759 s ±  0.013 s    [User: 43.850 s, System: 0.065 s]
  Range (min … max):    3.744 s …  3.786 s    10 runs
 
Benchmark 6: LD_LIBRARY_PATH=. ./flac -8ep -j 16 01.wav -o result.flac
  Time (mean ± σ):      3.650 s ±  0.036 s    [User: 56.519 s, System: 0.087 s]
  Range (min … max):    3.617 s …  3.732 s    10 runs
 
Summary
  LD_LIBRARY_PATH=. ./flac -8ep -j 16 01.wav -o result.flac ran
    1.03 ± 0.01 times faster than LD_LIBRARY_PATH=. ./flac -8ep -j 12 01.wav -o result.flac
    1.05 ± 0.01 times faster than LD_LIBRARY_PATH=. ./flac -8ep -j 10 01.wav -o result.flac
    1.08 ± 0.03 times faster than LD_LIBRARY_PATH=. ./flac -8ep -j 8 01.wav -o result.flac
    1.31 ± 0.01 times faster than LD_LIBRARY_PATH=. ./flac -8ep -j 6 01.wav -o result.flac
    1.87 ± 0.02 times faster than LD_LIBRARY_PATH=. ./flac -8ep -j 4 01.wav -o result.flac

Это на AMD Ryzen 7 5700X @ 4.66 GHz, 8 физических ядер, 16 виртуальных. Из результатов выше можно сделать вывод, что действительно серьёзный выигрыш по времени даёт увеличение количества потоков вплоть до количества физических ядер процессора. Дальнейшее повышение вплоть до количества виртуальных всё ещё даёт уменьшение времени, но уже не столь значительное, хоть и заметно больше погрешности.

Дополню, что, само собой, как и ожидалось, дальнейшее повышение количества потоков, выше числа «ядер», никакого выигрыша во времени кодирования не даёт, даже наоборот, становится пусть и едва заметно, но медленнее:

Benchmark 1: LD_LIBRARY_PATH=. ./flac -8ep -j 16 01.wav -o result.flac
  Time (mean ± σ):      3.588 s ±  0.023 s    [User: 56.136 s, System: 0.090 s]
  Range (min … max):    3.565 s …  3.639 s    10 runs
 
Benchmark 2: LD_LIBRARY_PATH=. ./flac -8ep -j 18 01.wav -o result.flac
  Time (mean ± σ):      3.610 s ±  0.010 s    [User: 55.754 s, System: 0.082 s]
  Range (min … max):    3.593 s …  3.628 s    10 runs
 
Benchmark 3: LD_LIBRARY_PATH=. ./flac -8ep -j 24 01.wav -o result.flac
  Time (mean ± σ):      3.625 s ±  0.016 s    [User: 56.506 s, System: 0.090 s]
  Range (min … max):    3.604 s …  3.653 s    10 runs
 
Benchmark 4: LD_LIBRARY_PATH=. ./flac -8ep -j 32 01.wav -o result.flac
  Time (mean ± σ):      3.620 s ±  0.007 s    [User: 56.909 s, System: 0.087 s]
  Range (min … max):    3.610 s …  3.631 s    10 runs
 
Summary
  LD_LIBRARY_PATH=. ./flac -8ep -j 16 01.wav -o result.flac ran
    1.01 ± 0.01 times faster than LD_LIBRARY_PATH=. ./flac -8ep -j 18 01.wav -o result.flac
    1.01 ± 0.01 times faster than LD_LIBRARY_PATH=. ./flac -8ep -j 32 01.wav -o result.flac
    1.01 ± 0.01 times faster than LD_LIBRARY_PATH=. ./flac -8ep -j 24 01.wav -o result.flac

точнее сказать не архиватор а сериализатор файлов тогда выражение «архиватор = сериализатор + компрессор/сжиматель» становится более логично
хотя все уже привыкли к архиватору :)

А также собирать и платить до*** за свет.

Пробовал, архиваторы в лучшем случае только близко подползают. Алгоритм специализированый, знает что делать.

При открытии СД-рипа в audacious на малине декодирование занимает 2-5 минут, а могло бы в 4 раза быстрее. При импортировании трека тоже мог бы жать в многопотоке так что не было бы смысла переключаться на что то другое.

А также собирать и платить до*** за свет.

tar -xvJf flac-1.5.0.tar.xz && cd flac-1.5.0 && ./configure && make -j8 у меня заняло 7.5 секунд. Комп потребляет пускай 800 ватт. На самом деле меньше, если не собирать, то тоже что-то потребляет, и надо брать разницу, но ок возьмём прям по максимуму, с запасом.

>>> (800 W * 7.5 sec) * 6.99 ₽/(kW×h)

    = 0.01165 ₽

Если для тебя 1 (одна) копейка — это «до***», наверное стоит оставить номер счёта в профиле — кто-нибудь сердобольный скинет тебе целый РУБЛЬ! Это сто раз по «до***».

Для gzip есть pigz, 100% совместимости, но многопоток только для сжатия. Не слышал о побочках, странно что ещё не в каждом дистрибутиве. А для pbzip2 и для сжатия и для распаковки, и вроде как даже заменяют стандартную версию ,по крайней мере в 7-zip точно.

Я в курсе сторонних костылей (см. выше), для flac они тоже в принципе имелись.

Это не костыли, это можно тупо симлинком заместить и будет лучше.

Ясно, спасибо за труд. Я подумал по аналогии с xz, там при многопоточном сжатии есть некоторое ухудшение.

Хочешь собрать свежаёший софт - бери сорцевый дистр. Берёшь сорцевый дистр - нефиг думать разрешая зависимости, пересбоирай сразу мир чтобы условный файерфокс тоже подхватил новую либу.

И вообще, мем такой был о генте.

Это не костыли

Как скажешь. Но в любом случае сторонние.

это можно тупо симлинком заместить и будет лучше.

Лучше будет, если наконец отказаться от gzip в 2025 году. Все давно перешли на zstd (по скорости сжатия близок к gzip, по скорости разжатия уделывает его подчистую, а по степени сжатия при этом ближе к xz). Ну или кому скорость важнее степени сжатия — на lzo и lz4.

Ну то metaflac, а речь-то про кодирование.

Т.е. многопоточность, это только про кодирование/декодирование? Я подумал, что metaflac шустренько пройдется по всем файлам и минут за пять все сделает. Я когда добавлял replay-gain теги во всю коллекцию так и не дождался конца, нажал Ctrl-C. А вот rsgain справился отлично, относительно быстро и с качеством лучше (все звучит с примерно одинаковой громкостью), чем сабж.

ЗЫ. В параллель внешними методами я не доверил.

Хочешь собрать свежаёший софт - бери сорцевый дистр. Берёшь сорцевый дистр - нефиг думать разрешая зависимости, пересбоирай сразу мир чтобы условный файерфокс тоже подхватил новую либу.

Зачем ты мне это пишешь?

Я комментировал только нелепый тезис про оплату электроэнергии. Что ты там ещё считаешь насчёт сборки софта и предпочтений в дистрах, меня интересует в данном случае очень слабо.

upd:

И вообще, мем такой был о генте.

Ясно. Не слышал. Ну тогда понятно хоть к чему это.

Т.е. многопоточность, это только про кодирование/декодирование?

Про кодирование. Насчёт декодирования не уверен (да оно там и не нужно, один хрен в I/O упирается скорее с нынешними мощностями в каждом утюге).

Насчёт metaflac не знаю, мне никогда не приходилось ждать при его использовании. Впрочем, я и replay-gain никогда не использую и всегда удаляю, если он есть. А удаляет он быстро — только считает, видимо, долго.

А сколько файлов было?