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

АЛАК тормозной и поддержка хуже.

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

На тот момент где-то 5300, сейчас 5615

А, ну тогда понятно… Ему же надо их все между собой сравнить и выдать что-то там среднее. Это же 30+ гигов музыки, я так понимаю? Оно и читаться-то не моментально будет (на HDD 4+ минуты одно только чтение файлов займёт), не то что считаться. И я не уверен, что помимо чтения это можно как-то хорошо распараллелить. Может и можно, но я не уверен. Впрочем, раз rsgain справился, значит что-то таки сделать можно (тут, правда, плюсом будет ещё то, что файлы в файловом кэше остались после метафлака).

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

В консольном 7.10 beta 3 такие:

    -mc<par>
            Set advanced compression parameters.

            Improper use of this switch may lead to suboptimal performance
            and compression. This switch has the following syntax:

            -mc[channels][mode][+ or -]

            where <mode> is the single character field defining
            the compression algorithm to be configured.

            Possible <mode> values are:

              D       - delta compression;
              E       - x86 executable compression;
              L       - long range search;
              X       - exhaustive search.

Интерсно, есть ли реальные преимущества…

wget https://archive.org/download/diffusion2023-07-03/diffusion2023-07-03.flac
flac -d diffusion2023-07-03.flac
rar a -m5 -mc2D+ mc2D.rar diffusion2023-07-03.wav
rar a -m5 -mcL+  mc2L.rar diffusion2023-07-03.wav
rar a -m5 -mcX+  mc2X.rar diffusion2023-07-03.wav

find -printf "%s  %P\n"

 93844366  diffusion2023-07-03.flac
294576552  diffusion2023-07-03.wav
136100152  mc2D.rar
170678228  mc2L.rar
169346515  mc2X.rar

А чего долгожданного в многопоточности? Если у тебя один трек, то запустил кодировщик фоном и пошёл заниматься своими делами. Если несколько, то запустил их кодирование в параллель и аналогично.

Что на практике даёт многопоточность кодировщика помимо усложнения кода?

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

Если у тебя один трек, то запустил кодировщик фоном и пошёл заниматься своими делами

Очевидно, что теперь можно не идти заниматься своими делами, а быстро получать результат.

Если несколько, то запустил их кодирование в параллель и аналогично.

А если не один, а альбом, где 6 треков, из которых интро — 1 минута, три трека по 4 минуты, один 6 минут, и один 16 минут?

Что на практике даёт многопоточность кодировщика помимо усложнения кода?

1. Экономию кучи времени.
2. Упрощение кода сторонних костылей, которыми до этого было обёрнуто практически всё у любителей музыки. Я, например, в куче мест смогу убрать Popen’ы со всеми вытекающими poll(), communicate() и прочим, в питоне, и кучу parallel в шелл скриптах. При этом это всё не только упростится, но и ускорится.

Жаль, что нельзя скримфейс и даблкофи одновременно поставить)

Это же 30+ гигов музыки, я так понимаю?

Побольше, сейчас:

$ & {                                                                             
        [int64[]] $sizes = (dir /data/Music/*.flac -s).size
        '{0} flacs, {1:f2} Gb' -f $sizes.count, ([linq.enumerable]::sum($sizes) / 1gb)
    }

5615 flacs, 162,05 Gb

Ага, логично. Я что-то прям совсем по минимуму взял :)

Ну 160 ГБ при всём желании нельзя «минут за пять» обработать, если они на HDD. Параллель, не параллель, а только читаться с HDD они будут больше двадцати минут — тут против ограничений железа не попрёшь. На SSD, конечно, намного веселее. Но вряд ли же ты музыку на SSD хранишь?

Но вряд ли же ты музыку на SSD

На одном из SSD, с внешним HDD (exfat) не комфортно, хотя на нем есть копия музыки.

Надо же, не знал, что так уже делают. Ну да, на SSD явно значительно шустрее будет по крайней мере чтение.

Кто «все»? По-моему совершенно плевать какая там степень сжатия и скорость (в пределах разумного), gzip ценен тем что он во всех смыслах кроссплатформенный - поддерживается всеми системами за последние 30 лет, и всем понятен. Везде, где есть польза от гонки на статами сжатия, есть специализированные (картинки, аудио и видео), а где ещё то сжатие такую важную роль играет? Времена дискет прошли давно, гонки за килобайтами неактуальны.

странно что ещё не в каждом дистрибутиве

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

ТС, сознайся, ты новость с опеннета «переводил»?

В оригинале:

When changing metadata, libFLAC now detects when an input file is a symlink, and will refuse to write data to it when an in-place rewrite of the metadata cannot happen

Написано кривенько, но догадаться можно: если нельзя обновить теги на месте и файл является симлинком, то процедура «(1) записать временный файл, (2) оригинал удалить, (3) временный файл переименовать» применяться не будет, т. к. это приведёт к замене симлинка на копию файла с новыми тегами.

Опеннет перевёл это так:

В libFLAC, libFLAC++ и metaflac реализована поддержка записи в новый файл при изменении метаданных, вместо перезаписи существующего файла. В libFLAC при изменении метаданных добавлена проверка указания символической ссылки в качестве входного файла и реализована защита от записи в подобные файлы при замене файла по месту.

Э-э-э… Кто на ком стоял? Канцеляризм во все поля, так, что понять смысл этих двух предложений невозможно.

Ну, и местная новость:

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

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

Походу, искусственный интеллект уже превзошёл естественный. Гуглоперевод оригинала более близок к оригиналу, чем опеннетные и лоровские «переводы»:

При изменении метаданных libFLAC теперь определяет, является ли входной файл символической ссылкой, и откажется записывать в него данные, если невозможно выполнить перезапись метаданных на месте.

Ну, flac жмёт норм.

Кто «все»?

Ну не прям все, конечно, это гипербола. Но всё больше и больше переходят. Например, на zstd для пакетов перешёл Арч. Всё чаще различные тарболлы распространяются тоже сжатыми им же. В SquashFS когда пакуют, используют в основном либо zstd либо lzo — поддержка gzip там тоже есть, но мало кому нужна.

gzip ценен тем что он во всех смыслах кроссплатформенный - поддерживается всеми системами за последние 30 лет, и всем понятен

zstd тоже всем понятен. Но да, именно по выше описанной причине gzip всё ещё кто-то использует в принципе, а не все повально перешли на что-то объективно технически лучшее, как только оно появилось. Это само собой.

Но прогресс не остановить. Иначе мы бы до сих пор zlib пользовались. И cpio.z.

Времена дискет прошли давно, гонки за килобайтами неактуальны.

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

Да и HDD тут от дискеты мало отличается — какую-нибудь, допустим, игры, приятнее хранить в tar.zst по 5 ГБ, чем в tar.gz по 7 ГБ. Два гига — это немного в наше время, казалось бы, но и храниться она может такая очень далеко не одна. Лишние гигабайты в итоге складываются в лишние сотни гигабайт и терабайты. Ну и распаковывается zst быстрее.

Жаль, что нет отметки об улучшении степени сжатия, хотя бы на «спортивные» 0.05%.

Да, я в курсе, мать писала.

zstd тоже всем понятен

Нет, разумеется. Лично я помню zlib api (как ему подать на вход данные, откуда забирать результат и вообще как организовать рабочий цикл для потокового сжатия/разжатия), применял его кучу раз в разных местах, а вот какое апи у zstd даже не знаю.

Чем меньше архив качать, тем быстрее

Какой архив? Что в нём сжато?

какую-нибудь, допустим, игры, приятнее хранить в tar.zst по 5 ГБ, чем в tar.gz по 7 ГБ.

Эм, кто игры в тарболлах хранит и зачем? И в нормальном случае всё тяжёлое (текстуры и мультимедиа) там и так сжато кодеками, а всё остальное погоды не сделает, можно хоть вообще чистым tar-ом паковать.

Степень сжатия в 1.4 улучшили. Здесь всё по-прежнему в этом смысле.

Какой архив? Что в нём сжато?

Да что угодно. Хоть те же исходники.

Эм, кто игры в тарболлах хранит и зачем?

Эм… Все, кто хранит игры (те, что не в gog-инсталлерах, в которых вообще .zip внутри)? Это странный вопрос.

И в нормальном случае всё тяжёлое (текстуры и мультимедиа) там и так сжато кодеками

К сожалению, мы живём не в «нормальном» мире. По крайней мере не в таком, который вы называете нормальным.

Да что угодно. Хоть те же исходники.

Если это не исходники какого-нить браузера то опять же степень сжатия никто не заметит.

Эм… Все, кто хранит игры? Это странный вопрос.

Зачем в тарболлах то? Мне такая идея никогда в голову не приходила почему-то, проще хранить в нативном виде.

К сожалению, мы живём не в «нормальном» мире. По крайней мере не в таком, который вы называете нормальным.

А конкретнее? Там видео и звук в raw форматах и картинки в bmp?

Если это не исходники какого-нить браузера то опять же степень сжатия никто не заметит.

Ну если качать одну небольшую утилиту, то да. А когда их сотни и тысячи?

Зачем в тарболлах то? Мне такая идея никогда в голову не приходила почему-то, проще хранить в нативном виде.

Что значит в нативном? Нативный — это для многих игр (скажем с itch.io или сайта разработчика) — это как раз тарбол. Из Стима — это россыпь непожатый файлов, которые мало того, что будут занимать, скажем, 12 ГБ вместо 3 ГБ на игру, так ещё и передать кому-то неудобно, да и вообще

Понятно, что если это инсталлер от GOG, то его пережимать никто не будет. Там .sh с .zip вовнутрях.

А конкретнее? Там видео и звук в raw форматах и картинки в bmp?

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

Но да, и звук в wav бывает нередко, и картинки в непойми чём растровом без сжатия (видимо, тупо дамп того, как оно в памяти), и чего только не бывает.

Важнее сам эмпирический факт: подавляющее большинство игр прекрасно жмётся в двое-трое, иногда и сильнее.

Иногда бывают совсем вопиющие случаи, как Cuphead, который весил около 12 ГБ, а пожатым — 680 МБ или около того (прям точную цифру не помню сейчас из головы). Потом поправили, вроде бы, и игра стала весить меньше, но всё равно жмётся. Но это вопиющие, конечно, случаи, обычно в 1.5–5 раз жмётся.

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

Белый шум не жмётся.

Имеются в виду не случайные биты со 100% энтропией, а белый шум в аудио, в wav.

Но я таки ошибся, флак всё же лучше жмёт, чем xz -e9, даже если шум. Хотя, как и ожидалось, оба справляются весьма так себе.

-rw------- 1 user user 855530 Feb 12 13:15 audiocheck.net_whitenoise.flac
-rw------- 1 user user 882046 Feb 12 13:12 audiocheck.net_whitenoise.wav
-rw------- 1 user user 860604 Feb 12 13:12 audiocheck.net_whitenoise.wav.xz
-rw------- 1 user user 849264 Feb 12 13:15 audiocheck.net_whitenoisegaussian.flac
-rw------- 1 user user 882048 Feb 12 13:13 audiocheck.net_whitenoisegaussian.wav
-rw------- 1 user user 870776 Feb 12 13:13 audiocheck.net_whitenoisegaussian.wav.xz

Шум отсюда: https://www.audiocheck.net/testtones_whitenoise.php

Тема крутая, но всё ещё для избранных))

А если не один, а альбом, где 6 треков

И в формате IMG+CUE при этом. ;)

Bandcamp немного выделяется — там не стриминг по подписке, а покупка музыки.

Еще он выделяется тем, что там каждый васян может разместить свою музыку, в отличии от.

Bandcamp был приобретён компанией Epic

Не знал, музыко в опасносте!

Многопоточное кодирование доступно и в libFLAC, и в утилите командной строки.

Много «И»)

2025-й же, почему нет?

root@walkbook:/home/rain# smartctl -a /dev/nvme0n1 | grep ^Model
Model Number: Samsung SSD 980 PRO 2TB
root@walkbook:/home/rain# smartctl -a /dev/sda | grep Model:
Device Model: MT-2TB
root@walkbook:/home/rain# du -sh /mnt/storage/music/
678G /mnt/storage/music/

Ноут.

В SquashFS когда пакуют, используют в основном либо zstd либо lzo

Вроде был zstd или xz. По крайней мере последний во всяких прошивках вижу. Раньше там был gzip, но очень давно.

Из Стима — это россыпь непожатый файлов, которые мало того, что будут занимать, скажем, 12 ГБ вместо 3 ГБ на игру, так ещё и передать кому-то неудобно, да и вообще

Ну качаются они таки в сжатом виде. Если передать в том смысле, что принимаемому качать из интернета тяжело, то можно через механизм бекапа. Но у принимающего игра должна быть тоже куплена.

подавляющее большинство игр прекрасно жмётся в двое-трое, иногда и сильнее.

Потому что юнити.

Еще он выделяется тем, что там каждый васян может разместить свою музыку, в отличии от.

Да, этим тоже. Ну вообще можно разместить ещё на Soundcloud и много где ещё бесплатно. А вот за денежку — Bandcamp лучший вариант пока. И для слушателя, желающего поддержать любимого музыканта, а не левый сервис, тоже. Правда с ситуацией в мире выводить с PayPal’а (через который они рассчёты с музыкантами ведут) стало доступно разве что довольно окольными путями…

Что значит в нативном?

Это в том из которого она запускается.

12 ГБ вместо 3 ГБ на игру

Ужас какой. Ладно, пусть так, просто мне повезло с этим не сталкиваться.

Потому что юнити.

Это не причина. Точнее не напрямую. На юнити тоже можно сжать внутри .assets. И на других движках тоже часто всё сжимается. Но косвенно поэтому тоже. Юнити позволяет «не особо-то и программистам» реализовывать свой творческий потенциал и делать игры. А когда такие люди становятся основой геймдева, об оптимизации задумываться перестают. В том числе и окружающие — ибо смысла нет.

Вроде был zstd или xz. По крайней мере последний во всяких прошивках вижу. Раньше там был gzip, но очень давно.

Сейчас поддерживаются zstd, xz, lzo, lz4 и gzip. После включения zstd в ядро и прекращения поддержки древних релизов дистров с совсем старыми ядрами, в основном все стали юзать zstd, потому что он быстрый на разжатие (и соответственно читается всё быстрее, чем тупо в ФС на HDD без сжатия), а жмёт при этом сравнимо с xz. xz тоже иногда используют, когда скорость не важна, но он медленнее, в тестах видно. Например, возвращаясь как раз к обсуждённым ранее играм, загрузки в играх в squashfs с zstd бстрее, чем в squashfs с xz или просто голыми на харде. Так что зависит от ситуации, и насколько имеет значение скорость. Когда хочется прям совсем-совсем быстро даже на каких-то портативных «калькуляторах», могут заюзать lzo или lz4, но довольно редко всё же. gzip раньше юзали, теперь очень редко.

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

Сравнил с https://github.com/hxim/paq8px (там есть автоопределение wav):

wget https://cdn.openai.com/whisper/draft-20220913a/micro-machines.wav

Но да, очень-очень медленно, что неудивительно:

time flac -1 micro-machines.wav
real    0m0.072s
user    0m0.029s
sys     0m0.000s

time paq8px -1 micro-machines.wav
real    6m36.341s
user    6m35.675s
sys     0m0.108s

find -printf "%s  %P\n"

5272390  micro-machines.wav
 756243  micro-machines.wav.paq8px208fix1
 984375  micro-machines.flac

Да я не против. Просто у большинства всё же подобные данные (для которых при воспроизведении скорость чтения не важна, то есть музыка и видео) до сих пор хранятся на HDD, ибо дешевле.

flac -1

Ну ты бы ещё с -0 сжал. В 2025-м никто даже дефолтное -5 не юзает. -8 стандарт де-факто, хотя многие (включая меня) используют -8ep.

Это же 30+ гигов музыки

6Tb

хотя многие (включая меня) используют -8ep

real    0m2.397s
user    0m2.394s
sys     0m0.000s

876847 bytes

Ну вообще можно разместить ещё на Soundcloud и много где ещё бесплатно.

Ну, по факту, многое есть только на Bandcamp. Если его просрут как MySpace, будет печально.

Ну вообще можно разместить ещё на Soundcloud

Только туда вроде как сабж не завезли.

-8ep

Что это дает? Я привык просто -8

Ещё чуть более сильное сжатие (экономия как раз примерно 0.2–0.5%) за счёт намного большего времени сжатия. Но мне место важнее, 30 секунд вместо 5 на сжатие альбома я как-нибудь перетерплю. Зато на каждые 200 альбомов экономится место ещё для одного. На любителя, конечно, выигрыш в свободном месте и правда не особо большой.

Что 6 Tb?

Чувствую себя как в анекдоте про «приборы»…

Да, всё так.

Да? Я никогда им не пользовался просто. Так, к слову вспомнил, что некоторые начинающие музыканты ещё бывает там выкладывают. А ещё там выкладывают те, кто не может выложить куда-то ещё из-за проблем с авторскими правами (всякие любители ремиксов и каверов и т.п.)

у меня музыки только пары направлений - 6 терабайт во flac.