Кодек эффективней flac

Судя по сравнению, это TAK

ужать свои 270Гб

это я так примерно в 1998 пережимал zip в rar

Ну ты же понимаешь, что для «без потерь качества» есть теоретический предел? Иначе это архиватор Бабушкина, а не кодек.

Хотелось бы ужать свои 270Гб

Всего-то? Два WoW-а :)

Вдогонку.

270Гб

Кстати, такую коллекцию вполне можно разместить на полутерабайтном (с запасом) внешнем HDD, для флака (по крайней мере, традиционного, на 44 кГц и всё такое) быстродействия USB должно хватать с головой. И даже бэкапить на другой такой же HDD, а то мало ли (вот время бэкапа огорчит, конечно – но его и не каждый день надо делать).

Я даже задумался о цене вопроса и нашёл, например, вот такую Тошибу. Интересно, как у неё с надёжностью, цена для известного бренда подозрительно низкая…

Короче, терять время и морочиться с малоизвестными кодеками с риском, что оно где-то на соседнем девайсе не прочитается и др. – я считаю в данном случае совершенно нерациональным занятием. Мнение моё, никому не навязываю.

Не появился кодек без потерь качества для аудио, который жмет лучше flac? Хотелось бы ужать свои 270Гб

Если у тебя настолько критическая ситуация, что ты готов пережимать flac ради нескольких процентов, то лучше тогда конвертируй в opus 192kbps и все.

Судя по сравнению, это TAK

OptimFROG же.

[B] Lower is better: Compression ratio is compressed size/uncompressed size * 100%.

Сильно надеюсь, что из-за 2.4% ТС заморачиваться не будет. Я бы точно не стал.

Меня смутило то, что он не опенсурс:

 OFR cons

    Closed source
    No multichannel audio support
    No hardware support
    Very slow decoding
    Slow encoding
    More than one tagging method allowed (ambiguity possible)

Ну и ТАК я когда-то пробовал, оба есть в AUR.

Меня смутило то, что он не опенсурс

Да, я сейчас тоже там был. :)

Хотя и к ТАК есть претензия, у него в зависимостях wine, наверное пробовал еще под виндой.

2.4%

Кто бы сомневался. Экономия на спичках как раз в духе ТС. А вот удобство сразу сливается. Например кроме flac и alac контейнеров теги нормальные никуда так и не завезли. Совместимость с разным софтом, включая мобилы, тоже сильно различается, я например держу на терабайтной мылосрушке часть музыки и могу проигрывать flac прямо из приложения или браузера.

Если интересно, есть https://github.com/slmdev/sac:

Sac is a state-of-the-art lossless audio compression model

Lossless audio compression is a complex problem, because PCM data is highly non-stationary and uses high sample resolution (typically >=16bit). That’s why classic context modelling suffers from context dilution problems. Sac employs a simple OLS-NLMS predictor per frame including bias correction. Prediction residuals are encoded using a sophisticated bitplane coder including SSE and various forms of probability estimations. Meta-parameters of the predictor are optimized with DDS (wiley.com) on by-frame basis. This results in a highly asymmetric codec design.

This program wouldn’t exist without the help from the following people (in no particular order):

Matt Mahoney, Dmitry Shkarin, Eugene D. Shelwien, Florin Ghido, Grzegorz Ulacha

Technical features

• Input: wav file with 1-16 bit sample size, mono/stereo, pcm
• Output: sac file including all input metadata
• Decoded wav file is bit for bit identical to input wav file
• MD5 of raw pcm values

Technical limitations
Sac uses fp64 for many internal calculations. The change of compiler options or (cpu-)platform might effect the output. Use at your own risk and for testing purposes only.

Benchmarks

Sac v0.7.18

16 files (44.1Khz, stereo) - 51.014.742 bytes - parallel on i7-13700H

Asymmetric encoding profiles - bits per sample (bps) is mean bps over all files

Profile		Size	Enc-time	Dec-time	bps
FLAC -8pe -P0	100.0%	29.621.631	00:00:02	00:00:00	9.330
–normal	90.1%	26.691.217	00:00:22	00:00:20	8.401
–high	89.6%	26.546.317	00:03:42	00:00:50	8.352
–veryhigh	89.4%	26.480.793	00:17:38	00:00:53	8.330
–extrahigh	89.3%	26.453.344	00:48:46	00:00:52	8.322
–best	89.1%	26.397.759	04:37:00	00:01:00	8.303

Интересно, но вряд ли захочу переконвертировать 200 Гб:

Artists            : 211
Albums             : 581
Total Tracks       : 6868
Average Play Count : 4.25
Average Rating     : 4.63
Total Duration     : 21d 18h 51m

Помимо самой коллекции, придется переписывать сопутствующие скрипты

Что значит «не появился»? Они уже лет 10+ как есть. Даже ныне (полу)умерший APE жал лучше, если сравнивать исключительно степень сжатия. Ну а так есть ещё tak, optifrog. Другое дело, что разница не достаточно впечатляющая и несёт с собой издержки (как минимум самое очевидное — совместимость, но ещё могут быть проблем с seek, сложностью декодирования, из которой следует большая нагрузка на CPU и соответственно энергопотребление при проигрывании, и прочее-прочее), поэтому в большинстве юзкейсов проще всё же держаться за FLAC. Плата за пару-тройку процентов сэкономленного места получается слишком велика.

04:37:00 00:01:00

Четыре с половиной часа жать одну песенку, чтобы сэкономить 3 мегабайта (а потом по минуте процессорного времени тратить при каждом прослушивании) — это сильно, конечно…

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

Посчитал ради прикола, если с той же скоростью, что в таблице, сколько времени уйдёт на то, чтобы пережать мой коллекцию из FLAC в этот sac с --best. Получилось чуть больше чем 20 лет чистого времени только на переконвертирование:

1151766747635 byte / (29621631 byte / (04 hour + 37 minute)) → year

    = 20.4782 yr    [Time]

Там правда в этом объёме ещё немного обложек есть и совсем чуть-чуть всяких .log и .cue… Ну в общем, до 20 лет можно округлить за счёт этого :)

P.S. Если с --normal, то «всего» за 10 дней можно управиться. Чистого времени со 100% нагрузкой на проц…

Надо на gpu портировать

берем коэффициент сжатия flac - 52, а OptimFROG - 49,6%. объем 270Гб
выигрыш (270/52)*(52-49,6)= 13,5 Гб ( 4,6% ).
на уровне погрешности.
при этом ловим неимоверную проблему распространенности кодека…

Тышто! У меня в 1999 был винт IBM аж на 14 Гб. Считай целый диск потеряли.

мой первый винт воообще был 2,5Гб. а сейчас на телепоне 3гб РАМЫ и всё - телефон менять надобно !! а десяток гигов это сборка фоток с отдыха девицы…

на уровне погрешности.

Ну нет конечно. Сильно выше погрешности и в целом привлекательно, если бы это был flac. Но не такой ценой.

P.S. Сравнение, кстати, не актуальное, скорее всего. В FLAC где-то в районе 1.4 повысили эффективность сжатия. Не сильно, где-то на 0.5%, ЕМНИП, но всё же в таких сравнениях всё имеет значение.

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

тут есть два подхода:

1. отказаться от lossless

2. использовать ИИ для разделения треков на дорожки и конвертирования инструментальных в MIDI + wavetable. При проигрывании midi и вокал (если есть) сводится вместе.

какиенить банки звуков, огибающих, базовых сигналов с кодеком таскать…

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

Второй вариант по сути является частным случаем первого, только «высокотехнологичным».

Даже ныне (полу)умерший APE

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

А ведь когда-то именно APE на трекерах был стандартом. Потом FLAC и WavPack его потеснили. Победа опенсорса налицо :)

Это было так давно, что можно уже сказать, это неправда. :)

Четыре с половиной часа жать одну песенку, чтобы сэкономить 3 мегабайта (а потом по минуте процессорного времени тратить при каждом прослушивании) — это сильно, конечно…

Взял https://archive.org/download/diffusion2023-07-03/diffusion2023-07-03.flac (93844366 байтов) из примеров whisper.cpp, конвертировал в .wav (294576552 байта).

$ sac --mt-mode=2 diffusion2023-07-03.wav diffusion2023-07-03.sac:

Sac v0.7.26 - Lossless Audio Coder (c) Sebastian Lehmann
compiled on Jun 23 2026 (64-bit,AVX2) gcc 15.3.0

Open: 'diffusion2023-07-03.wav': ok (294576552 Bytes)
  WAVE  Codec: PCM (1411 kbps)
  44100Hz 16 Bit  Stereo
  73644127 Samples [00:27:49.935]
Create: 'diffusion2023-07-03.sac': ok
  Profile: mt2 20s ab zero-mean sparse-pcm

  73644127/73644127: 100.0%
  Timing:  pred 70.12%, enc 29.10%, misc 0.78%
  MD5:     ab64f1897f9444d335036a5247548b5

  294576552->83731803=28.4% (4.548 bps)  1.750x

  Time:    [00:15:54]

Получился diffusion2023-07-03.sac (83731803 байта).

сколь помню все lossless основаны на lossy, которое дает основное сжатие + вычисление ошибки и эту ошибку сжимают без потерь.
т.е. улучшение сжатия lossy даст прирост сжатия и всего lossless.
но согласен, не математик я… :)

сколь помню все lossless основаны на lossy, которое дает основное сжатие + вычисление ошибки и эту ошибку сжимают без потерь.

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

не :) вот прям из википедии про flac

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

А можно не страдать ерундой с lossless и пережать в Opus 256

Так у него кодек закрытый и только под винды. И судя по беглому осмотру (давно смотрел) написан на Дельфях.

В общем заменить flac нечем. Жаль, было бы приятно 250гб превратить в 100гб

Судя по сравнению, другим кодеком ты сильно места не сэкономишь, так что снижай лучше качество аудио до 16 бит и 44 кГц.

Можно просто пережать FLAC сильнее, т.к. часто сжимают не "-8", а "-6" или "-5". Возможно, что 1ГБ свободный заимеешь.

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

Поэтому повторно предлагаю внешний HDD (см. выше).

было бы приятно 250гб превратить в 100гб

Хы. Тут не помешает губозакатывательная машинка.

Нет, при большом желании можно, конечно. Как раз если в лосси пережать (Opus, например), где-то так и выйдет. Но зачем?..

Лучше просто купить HDD хотя бы терабайт на 16 и не переживать больше о такой мелочи.

Лучше просто купить HDD хотя бы терабайт на 16 и не переживать больше о такой мелочи.

Переживать об этом придётся, потому что синкается на телефон, а там никогда не будет такого объема

Это типа особый вид архиваторов

Нет.

заточенных только на сжатие звука, плюс свой контейнер

Да, это особый вид компрессоров, заточенных на сжатие звука, плюс опционально свой контейнер. Архивированием они при этом не занимаются. Хотя в каком-то смысле можно назвать архивом «образ» диска, где все треки склеены в один длинны, и к этому приложен cue, но кодек как таковой тут ни при чём — это можно сделать с любым кодеком, или даже вообще с сырым PCM-сигналом.

Но насчёт основанности на lossy сказано правильно в каком-то смысле, в этом и заключается заточенность на сжатие звука, собственно. Если очень упрощённо (на деле чуть сложнее, зависит от кодека, и могут быть также вариации в зависимости от данных), то сперва два канала подгоняются под общий знаменатель, затем кодек пытается аппроксимировать этот сигнал функцией — так близко, как это возможно — получается такой вот лосси-сигнал, аппроксимированный; затем вычисляется разница этого аппроксимированного сигнала с исходным, и она уже жмётся «в тупую» наименьшим возможным количеством бит, как эдакий довесок. При декодировании соответственно генерируется вот этот вот аппроксимированный сигнал при помощи функции, и к нему прибавляется тот самый «довесок», в итоге получается сигнал, идентичный исходному.

Я когда не телефоне слушал, тупо закидывал туда в aac (у меня тогдашний телефон не умел в Opus, сегодня я порекомендую его), хотя на компе хранил лосслесс. Там всё равно ЦАП всратый в любом телефоне, да и наушники тоже не хайэнд обычно используются, поэтому всё равно разницы не услышишь даже при желании.

Можно сделать скрипт или даже FUSE псевдо- файловую систему, чтобы при «скидывании» на телефон музыки пережатие делалось прозрачно. На современном компе это будет даже быстрее простого копирования, скорее всего, потому что передавать и записывать на относительно медленный носитель в телефоне надо будет меньше байт.

Копию для телефона лучше пережать в lossy с хорошим битрейтом. Очень удобно это делается в DeadBeef, например.

Я к телефону подключаю ЦАП и использую его в качестве источника звука для прослушивания музыки на полочных колонках с усилком

Может я что-то не понимаю, а может зажрался со своими терабайтами, но как мне кажется 270GB - это вообще ни о чём. К тому же как выясняется, слушать это планируется на телефоне, а не на студийных мониторах в спец. комнате. Зачем на телефоне lossless? Короче, вообще надо хранить две копии каждой записи - оригинал и сжатый с потерями «расходник». У меня многое сразу в расходниках, поскольку оригинал или утерян или изначально не найден. Расходники закачиваются на телефон (ну или куда там) для прослушивания, а оригиналы хранятся, как здесь многие уже советовали на специально купленном для этой цели 300GB внешнем диске на полочке. Рядом надпись «Осторожно, ценные звукозаписи, грязными руками не трогать!»

у меня тогдашний телефон не умел в Opus, сегодня я порекомендую его), хотя на компе хранил лосслесс

Проблема Opus еще в том, что там принудительно 48 кГц. Получается я беру трек 44.1 FLAC, конвертируется в 48к, потом при воспроизведении на телефоне опять в 44.1к. С одной стороны, понятно, что на фоне лосси компрессии, потери от ресемплинга ничтожны, но с точки зрения инженерного перфекционизма, это сильно коробит.

Короче, вообще надо хранить две копии каждой записи - оригинал и сжатый с потерями «расходник»

Нафейхоа? Жать можно на лету при отправке на телефон.

Я к телефону подключаю ЦАП и использую его в качестве источника звука для прослушивания музыки на полочных колонках с усилком

А что мешает стримить FLAC с компа на телефон тогда.

А… Ну тогда не знаю. Может, раз уж всё равно это дома слушается, и ЦАП подключается, то и HDD подключать к нему?

Получается я беру трек 44.1 FLAC, конвертируется в 48к, потом при воспроизведении на телефоне опять в 44.1к. С одной стороны, понятно, что на фоне лосси компрессии, потери от ресемплинга ничтожны, но с точки зрения инженерного перфекционизма, это сильно коробит.

Есть такое. Но лучше всё равно ничего нет ¯\_(ツ)_/¯