Кодек эффективней 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

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