ТОТАЛЬНОГО СЖАТИЯ ТХРЕАД Android: Mobile Safari 2686610 В конец треда | Веб
Унижаем PNG-блядей, ждем ввода WebP и AV1, пишем Нариману Абу в /d/, отправляем на свалку H264/vp8, кодируем минутный ШебМ джва часа.
Православная утилита кодирования - FFmpeg:
https://www.ffmpeg.org/
Вики по использованию :
http://trac.ffmpeg.org/wiki
GUI - FFmpeg Batch:
https://sourceforge.net/projects/ffmpeg-batch/
.gif3 Мб, 400x240
Windows 10: Firefox based 2 2686616
>>686610 (OP)

>ждем ввода WebP и AV1, пишем Нариману Абу в /d/


Долго будете ждать.
1573752083417.jpeg46 Кб, 1080x608
Android: Mobile Safari 3 2686619
Третьего дня по совету проверенного поискового гиганта эксперементирую с новым мегаформатом webp, задыхаясь от жадности к хранилищу, перекодировал пак трапов. Размер и качество, мое почтение, хорошо сделали. Кроме того, удаление шумов и артефактов приятно щекочет простату. Был решительно готов закодировать все фото, однако, малолетнему кодеру невдомек, что метаданные удалять не стои. Как побороть проблему?
Linux: Firefox based 4 2686650
>>686616
когда сделают на фчане, абу запилит сюда через неделю-две. с вебмами так же было, хотя вебмы действительно более значимы.
1.jpg43 Кб, 550x368
Windows 10: Firefox based 5 2686662
>>686610 (OP)

>WebP


Так работает же, не?
Windows 10: Firefox based 6 2686664
>>686662
А не, пизжу, не работает.
Windows 10: Firefox based 7 2686673
>>686610 (OP)

> WebP


Очередной зонд пиздящий данные пользователей через метадату. Хотя что еще ожидать от компании специализирующейся на ботнетах.
Windows 10: Firefox based 8 2686686
>>686673

>пиздящий данные пользователей через метадату


Каким образом это происходит?
Android: Mobile Safari 9 2686744
>>686673
У меня как раз обратная проблема: он не сохраняет метадату из жпега
1573832496536.jpeg84 Кб, 606x800
Android: Mobile Safari 10 2686989
Windows 8: Chromium based 11 2687043
>>686989

учитывая что для vp9 нет хардварного энкодинга на gpu, HEVC сжимается хардварно на огромном количестве видимокарт, а сжатие vp9 занимает овердохуя времени имею сказать следующее - ебитес врот своим vp9

av1 ваще нахуй нинужон, по тем же причинам
Windows 10: Firefox based 12 2687048
>>687043

>HEVC


Не проигрывается в лисе.
Windows 8: Chromium based 13 2687053
>>687048

ну вот поэтому или скачивай hevc и проигрывай локально, или кушойти x264\vp8
Windows 7: Chromium based 14 2687233
из-за чего получается такой блок серый снизу? я просто перекодировал
fix.mp42 Мб, mp4,
704x572, 0:06
Windows 7: Chromium based 15 2687237
Android: Mobile Safari 16 2687291
>>687233

>m4v


Что это? Зачем?
.jpg45 Кб, 380x604
Linux: Firefox based 17 2687296
>>686610 (OP)
Новые люди, новое время, когда то по моим алгоритмом работало сжатие, один раз мы пытались сжать ядро планет, что бы получать неограниченное тепло, но математические алгоритмы не сработали!
Windows 10: Firefox based 18 2687384
Какие параметры использовать, если нужно просто к вебмке сабы добавить?
Android: Mobile Safari 19 2687387
>>687384
-vf subtitles=
походу
изображение.png109 Кб, 288x224
Linux: Firefox based 20 2687664
>>686610 (OP)
Вся суть вебп одной картинкой. Меньше артефактов - меньше деталей.
Алсо вебп, в отличие от того же heif не умеет в градиенты.
1574024326196.jpg26 Кб, 260x362
Android: Mobile Safari 21 2687671
>>687664

>меньше деталей.


Нет.

> Алсо вебп, в отличие от того же heif


Не опенсорс, уноси.

>не умеет в градиенты.


Эм что?
Windows 7: Firefox based 22 2687799
>>687671

>Нет.


Сравни облака, особенно слева.
Linux: Firefox based 23 2687866
>>686610 (OP)
Чем avif под пердолексом пожать?
Windows 7: Firefox based 24 2687876
1574121297671.png2,6 Мб, 3240x1742
Android: Mobile Safari 25 2688040
>>687799
Как этот хентай можно сравнивать с божественным вебпом?? Все детали жпега - это артефактная лестница
Windows 10: Chromium based 26 2688070
>>688040
png лучше всех, чтоб и требовалось доказать
Linux: Firefox based 27 2688074
>>688040
Этот хентай поддерживается в любом браузере, в любой перделке. Вебп - гуглоговно без задач.
pSm4JGlLxaI.jpg31 Кб, 480x319
Windows 10: Chromium based 28 2688166
>>688074
Говно мамонта
Windows 7: Firefox based 29 2688187
>>686650
Абу выпилил av1? Раньше нормально заливались шешебы.
Или вы про av1 для картинок?
Windows 10: Firefox based 30 2688238
>>686610 (OP)
А нахуй надо? Глобальное потепление приближать, но зато Абу за хостинг меньше платить?
Android: Mobile Safari 31 2688294
>>688187
Превью нет
japav1.webm4 Мб, webm,
630x350, 1:29
Windows 10: Chromium based 32 2688343
Android: Mobile Safari 33 2688356
>>688343
Эх тилибон через vlc не осилил
1574200229108.jpeg59 Кб, 1080x1920
Android: Mobile Safari 34 2688394
>>688356
Последняя версия?
.png973 Кб, 1000x750
Windows 7: Firefox based 35 2688538
>>687799
Даже авиф мылит.
Android: Mobile Safari 36 2688727
>>688538
А как еще реализовать сжатие?
Linux: Firefox based 37 2688736
>>688727
Имитировать детали артефактами, например? 30 лет так живём уже.
Можно было бы анализировать картинку и по маске псевдослучайный шум перлина натягивать, чтобы этой кожи младенца не было.
Linux: Firefox based 38 2688758
>>688736
Короче свёл исвудыча, чтобы размеры были одинаковые.
8576 clee.jpg (jpegoptim --size=8k)
8522 clee-26.webp (cwebp -q 26)
8251 clee-28.heif (heif-enc -q 28)
Android: Mobile Safari 39 2688759
>>688736
Но мыло лучше артефактов, особенно в движении. А шум это уже какая-то отсебятина.
Linux: Firefox based 40 2688764
>>688759
Мыло нужно видемокодекам, чтобы вектора движения долго можно было использовать и не накапливать ошибку.
В статических кодеках рулят другие принципы.
cleesub-78.webprlt.png302 Кб, 464x604
Linux: Firefox based 41 2688845
>>688758
Последний эксперимент: даунскел до 0.5, webp оптимизация до 8282 байт (-q 78) и последующий апскел через ESRGAN.
Android: Mobile Safari 42 2689773
>>688758
Хевк неплохо тут отработал. А размер точно одинаковый?
Windows 7: Firefox based 43 2689813
>>688736
Можно оригинал?
Windows 7: Chromium based 44 2689839
>>687799
Эхх, а сейчас там заборов понаставили, нипалазать.
Windows 7: Chromium based 45 2689974
Говорят, что ав1 будет лучше хевка. Что-то мне сдается, что это пиздеж. Даже хевк против х264 хуже в плане детализации. Сужу по примерам аниме, неоднократно делал сравнения.
clee.png375 Кб, 463x604
Linux: Firefox based 46 2690003
>>689813
Случайная фотка из инета была. Не гарантирую, что он предварительно не был пожат.

>>689773

> А размер точно одинаковый?


Размеры подписал. HEIF даже чуть меньше:
webp - 8522 байт
heif - 8251 байт
Linux: Firefox based 47 2690026
>>688538
>>687876
Короче енкодер avif я нашёл тут: https://github.com/Kagami/go-avif/releases
Где бы теперь декодер найти, чтобы без конпеляции и пердолинга?
Linux: Firefox based 48 2692135
Забил короче на avif, оставил jpg, webp и heif. Скрипт берёт картинку и жмёт тремя разными кодеками до одинакового размера.
Тут глаз в 4, 6, 8 и 10 кб.
res-clint-5k.png1,2 Мб, 1075x1432
Linux: Firefox based 49 2692137
Пятикилобайтный клинт.
res-logo-4k.png385 Кб, 1401x1368
Linux: Firefox based 50 2692142
Windows 8: Chromium based 51 2692143
>>692137
Норм
res-jackal-3k.png495 Кб, 521x756
Linux: Firefox based 52 2692145
>>687664
трёхкилобайтный шакал (jpegoptim тут схитрил и пожал до 3,9, но webp один хрен посасывает)
res-jackal-1k.png413 Кб, 521x756
Linux: Firefox based 53 2692148
Для ценителей.
res-8560-40k.png3,8 Мб, 2001x1532
Linux: Firefox based 54 2692149
Linux: Firefox based 55 2694527
>>692145
Здесь heif закодировал больше всего деталей, хотя заметны мазки внутрикадрового предсказания
heif > webp > jpeg
>>692148
Здесь heif сосёт.
Лицо как у куклы, выглядит пластмассово. Гиганские блоки с явными арктефактами звона. Внутрикадровый предиткор превратил брови в прямые линии.
webp > heif > jpeg
Linux: Firefox based 56 2694531
>>694527
>>692148
Когда писал тот пост не обратил внимания на размер. А там же jpeg и webp по 2 мегабайта весят, а heif 1 мбайт. Так сравнивать нечестно. Переделывай.
Linux: Firefox based 57 2694532
>>694531
*килобайта и кбайт соосветсвенно
Linux: Firefox based 58 2694541
>>686610 (OP)
Забыли ссылку на гайд по webm кодированию в шапку треда добавить
https://github.com/pituz/webm-thread/wiki/webm-encoding
Linux: Firefox based 59 2695096
>>694531

>Переделывай.


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

> webp > jpeg


Насчёт этого бы поспорил. Чисто внешне по количеству деталей webp тот же жипег, но у жипега артефакты уже приелись, а webpшное мыло реально глаза мозолит.
Linux: Firefox based 60 2695497
>>695096

>жипега артефакты уже приелись, а webpшное мыло реально глаза мозолит


то есть тебя не смущает убитая цветопередача вследствии задранного квантователя и примитивного алгоритма компрессии.
Как по мне вместо хранения ВЧ квантованных до металлического звона лучше срезать их НЧ фильтром и сохранить изображение в меньшем разрешении.
WEBP хотя бы пытается замаскировать блочность, как и h264 и всё что после него.
Главная проблема webp в том, что там даже не vp9, а устаревший vp8. Ещё одна проблема этого формата в том, что хоть там и взяли за основу видеокодек vp8, но анимации он сжимает только intra фреймами. Из-за этого гифки сжимаются в лучшем случае на 50%. Поэтому я в 2019м кодирую гифки в неудобный для infinite-loop анимаций формат webm.
Еще сейчас набирает популярность формат apng. Это lossless формат, который сжимает гифки на 5%. Да, у него есть преимущество перед gif, так как он может закодировать true color анимации без потерь, да еще и с настоящим альфа каналом. Но большинство гифок это нарезки из фильмов, зашумленные дизерингом из-за ограничения в 256 цветов на одном фрейме, и там это lossless кодирование не нужно в принципе.
Windows 7: Firefox based 61 2695667
>>695497

>apng


Для этой хуйни уже появились оптимизаторы, затирающие повторяющиеся части у последующих кадров?
Linux: Firefox based 62 2696059
1572172349459.png123 Кб, 471x513
Linux: Firefox based 63 2696104
>>686610 (OP)

>4 пик


Если не рассматривать картинку увеличенной в близи, то, ЖПЕГ безоговорочно лучше, больше деталей и информации сохранено.
Linux: Firefox based 64 2696469
>>696104
Во сколько раз нужно уменьшить картинку, что-бы jpeg стал лучше?
Linux: Firefox based 65 2696918
>>696469
На вдвое уменьшенном прекрасно видна разницу. Ноздря, складка меж глаз, морщина на лбу, текстура кожи, лысина за линзой очков.
DCT-8x8.png4 Кб, 438x438
Linux: Firefox based 66 2697986
>>696918

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


Я вижу низкочастотные (те которые в левом верхнем углу на пикрелейтед) базисы дискретно косинусного преобразования, а не детали. Их убил задранный донельзя квантователь. А от даунскейла низкие частоты смещаются к более высоким, а высокие пропадают, так как их срезают для предотвращения алиасинга. В данном случае мы не видим потерю высоких при даунскейле, поскольку их и небыло в данном пережатке.
Ubuntu Linux: Firefox based 67 2698030
>>696918
Tы слегка перепутал, jpg это то, что слева.
Windows 10: Firefox based 68 2698047
Как сделать свой кодек, который нагнет webp и прочие jpg?
Windows 7: Firefox based 69 2698104
>>698047
Никак, изучай плюсы, матан, питон, алгоритмы, нейронки, машоб
Linux: Firefox based 70 2698126
помгаю от шумов.jpg34 Кб, 720x300
Linux: Firefox based 71 2698128
Linux: Firefox based 72 2698130
>>698030

>Tы слегка перепутал, jpg это то, что слева.


Ну вот и говорит о том что с лева.
С лева видно больше деталей.
Linux: Firefox based 73 2698353
>>697986
Ты математику свою вшивую в оценку сжатия не неси. А то уже целое поколение долбоёбов выросло, которые музыкальные кодеки по спектрограмме оценивают.
Единственно корректная оценка методов сжатия - это визуальная оценка большинством живых людей.
Linux: Firefox based 74 2698471
>>698130
Свидетели деталей, что с вами не так?
Если закодировать mp3 в 32 кбит/c, задрав срез lowpass фильтра на 20кГц, используя кодировщик, псиоакустическая модель которого позволяет сделать такое, ты получишь больше частот, ценой увеличения металлического звона и общего снижения качества, так как на те-же частоты выделяется меньше битрейта.
В случае с ОП - пиком, там размер файла настолько мал, что на деталей бит не осталось, всё в квадратики ушло.

>А давайте мы снизим разрешение и посмотрим на квадратики еще и интерполяции. В jpeg квадратики больше, значит и деталей больше.


Так вы только снижаете разницу между кодеками

>Ты математику свою вшивую в оценку сжатия не неси.


Я может быть бы и молчал, если бы jpeg картинка не рассыпалась на эти самые базисы ДКП, и свидетели деталей тоже бы молчали.

>Единственно корректная оценка методов сжатия - это визуальная оценка большинством живых людей.


Кому то нравится пиксельное говно, кому-то зашакаленное, кому-то мыльное.
Я вижу, то что у webp отображается как линии и контуры, то у jpeg превратилось в кашу из блоков. А ведь линии и контуры это тоже детали.
Windows 10: Chromium based 75 2698570
>>698490 (Del)
Репорт.
1575741907878.jpeg7 Кб, 736x460
Android: Mobile Safari 76 2698576

>>2698490


Одобряю, работает
Android: Mobile Safari 77 2698582
>>698570
Привет подстилка нариманова
балмер одобряет.jpg18 Кб, 474x301
Linux: Firefox based 78 2698589
>>698471
Нет ноздри в твоём webp, пропала. Шакал без ноздри не шакал.

>Кому то нравится пиксельное говно, кому-то зашакаленное, кому-то мыльное.


Ну давай хоть MSE посчитай чтоле, идиота кусок.
jpeg основан НА МОДЕЛИ ВОСПРИЯТИЯ ЧЕЛОВЕКА, неважно что кому нравиться, он использует объективную метрику, может неидеальную, но основанную на объективных свойствах человеческого восприятия.

>Я вижу, то что у webp отображается как линии и контуры


Белое пятно лучше квадратных глаз и носа?
Без глаз и носа непонятно что это, человеческое лицо, или тупой фиолетовый двачер.
Windows 10: Firefox based 79 2698595
>>698570
Хорошая собачка, держи кость.
Linux: Firefox based 80 2698608
>>692149
WebP - замылил дорогу, замылил лес.
Потерял цвета на дороге.
Сделал логотип на строении слева ЧЕРНО-БЕЛЫМ.
1575744354814.png1,1 Мб, 1080x1497
Android: Mobile Safari 81 2698615
>>698608
Что за сука сжимала webp?
15737509022353.jpg268 Кб, 711x493
Linux: Firefox based 82 2698671
>>698589
Ты можешь сколько угодно усираться что

>jpeg основан НА МОДЕЛИ ВОСПРИЯТИЯ ЧЕЛОВЕКА


но он всё равно не может закодировать линии в 3,6кБ.
Здесь я специально обвел области на которых у webp линии более менее четкие в то время как у jpeg там каша из блоков
Windows 7: Chromium based 83 2699037
>>698128

>Канал связи с космосом


еще ни разу не открывался

>Закрывает третий глаз


как будто он существует

>блокирует чакры


и так заблокированы

>Убивает бога


убить можно только то что есть

>выводит пришельцев


то-то я в современной порнухе эти тентакли видел, это же инопланетные глисты
Android: Mobile Safari 84 2702958
Какой-нибудь просмотрщик уже может в avif?
Linux: Firefox based 85 2703135
>>702958
Только браузеры через avif.js.
Windows 10: Chromium based 86 2703394
>>702958
А кодировщик есть (XnviewMP)?
Windows 10: Chromium based 87 2703429
>>703394
Кидали
https://github.com/Kagami/go-avif
>>702958
VLC может, но это видеоплеер, не удобно.
Windows 10: Chromium based 88 2703433
>>703429
спосебо, но это говно какое-то.
Windows 10: Chromium based 89 2703440
Хуй знает как этот ваш heif жать, нашел какой-то онлайн конвертер, но он цвета проебал
Windows 7: Firefox based 90 2703677
>>703440
Перед тем, как выкладывать результаты в пнг, удаляй метаданные о цвете в tweakpng. Или же следи, чтобы они были одинаковые у всех пикч.
Linux: Firefox based 91 2703827
>>703440
avif>webp
Да, там деталей побольше, словно render distance выкрутили. Но облака мыльнее, да.
avif vs heif
Как это вообще сравнивать?
Возникает ощущение, что кодировщик heic вместо тебя редактирует уровни. Вы уж там разберитесь с full->tv->full range преобразованиями.
По детализации разница не большая, но heif кажется детальнее (это при том что avif сложнее кодировать). Может avif потом допилят по качеству. Пока они ускоряют декодеры.
Linux: Firefox based 92 2703913
>>703440
Вы сжимать webp не умеете
cwebp -size 46900 -z 9 -m 6 -f 100 '15764428295940.png' -o '15764428295940.webp'

Размер: 43,6КБ>>703440
Windows 7: Firefox based 93 2703964
Помогите объяснить необъяснимую хуйню. Я запостил в клиент вотсапа видео ролик, и если его проиграть - видно последний кадр. НО, если проиграть его в VLC или даже открыть в VirtualDub - этого кадра там нет! Это как блять?

Ролик и два скрина - с ватсапа и VirtualDub - последние кадры. И они не совпадают.
Linux: Firefox based 95 2711339
>>709158

>libx264 slow 320k (6s)


>libx265 slow 320k (55s)


>libvpx-vp9 320k (3m)


>libaom-av1 320k (6h 15m)


Зачем так кодировать? Как можно сравнивать x264 закодированный за 6 секунд с av1, который кодировался 6 часов?
Если уж и сравнивать, то на placebo, ну или в крайнем случае на veryslow.
Linux: Chromium based 96 2711433
>>711339

>Если уж и сравнивать, то на placebo, ну или в крайнем случае на veryslow.


На таком битрейте будет одинаково хуевым.
Windows 7: Firefox based 97 2711629
Sup, подскажите как достать аудио дорожку из видео. А после склеить с видеорядом лучшего качества.
Android: Mobile Safari 98 2711633
>>711629

Достаем звук:
ffmpeg -i видос.webm -vn -c:a copy звук.opus

Удаляем звук:
ffmpeg -i хороший_видос.webm -c:v copy -an хороший_видос_без_звука.webm

Склеиваем:
ffmpeg -i хороший_видос_без_звука.webm -i звук.opus -c:v copy -c:a copy готово.webm
Windows 7: Chromium based 99 2711655
>>711633
а какого-то гуи для этого вашего ффмпега не изобрели еще? чтоб не печатать 100 символов а сделать 5 кликов?
Android: Mobile Safari 100 2711749
>>711655
Есть много гуев, но не очень то и нужно.
Windows 10: Firefox based 101 2711750
>>686610 (OP)
webp lossless как замена .png? Годнота! Практически во всех случаях webp получается меньше, а в среднем процентов на 20%
.
webp lossy как замена .jpg? Хуета! Нет, не так, webp lossy - в принципе хуита. Даже на 100% проёбывает непозволительное количество информации и совершенно отвратительно работает с градиентами.

Так что в своей картинкпомойке перевел png в webp, а jpg различной степени сжатости пришлось оставить jpeg'ами разве что pingo'й прогнал.
Linux: Firefox based 102 2711766
>>711750
Соглы.
Разве что heif сейчас вполне доступен стараниями эпола. Для лосси он уже однозначно обходит жопег.
Windows 7: Firefox based 103 2711814
>>711750

>webp lossless


Через чего кодируешь и с какими параметрами?
Windows 10: Firefox based 104 2711942
>>711814
xnconverter, сжатие на шестерочку.
Неизвестно 105 2712556
>>711655
Мокрописьки не нужны. Почти все графические видеоредакторы/конверторы и есть гуи к ффмпег.
FLIF.png352x304
Windows 10: Firefox based 106 2712559
>>686610 (OP)
Зачем нужен корпорастический webp, когда есть flif?
Windows 10: Firefox based 107 2712617
>>712559
Затем что вебп открывается?
Windows 10: Chromium based 108 2712631
>>712559

> FLIF.png

Linux: Firefox based 109 2712647
В интернете встречаются картинки порой огромных размеров, таких как 7000х7000, которые очень долго декодируются на Core2duo.
Были перспективы за вейвлетными форматами, что например для отображения эскиза будет декодироваться маленькая часть файла, вместо декодирования всей картинки целиком, что не нужно будет создавать эскизные копии одного и того-же, что для отображения на экране 1024x768 будут декодироваться только часть картинки до 875х875, а не вся картинка целиком и декодироваться оно будет быстрее. Но что-то не влетело. Вместо этого появился jpeg2000, который опять разбивает картинку на блоки размеров в степени двойки, который долго кодируется и долго декодируется.
И вот на свет выходит FLIF, который хвастается своей прогрессивной загрузкой, которая суть всё тот-же ебаный интерлейсинг, который был ещё в гифках и png. Хочешь наделать эскизов? Декодируй картинку полностью нагружая CPU и забивая оперативку до свопа.
Android: Mobile Safari 110 2712679
>>712647
Современные кодеки ставят целью максимальное сжатие, а тобою описанное — залупа в колёсах. Тем более, сейчас в любом шаёми 8 вёдер и 4+ гб озу.
Linux: Firefox based 111 2712699
>>712679

>сейчас в любом шаёми


>Xiaomi Redmi Go 1/16Gb


>4 ядра

Linux: Firefox based 112 2712701
>>703913
Всеравно говно.

>>711750
Двачую.
Linux: Firefox based 113 2712764
>>712647
просматривал свой пак картинок. Оказалось что aritmetic jpeg тормозит сильнее чем webp. Причём aritmetic jpeg тормозит на картинках если размер больше чем 1000х1000, а webp если больше чем 2500х2500. И еще мне показалось что lossless webp меньше лагает чем lossy webp
Неизвестно 114 2713070
>>711633
Ну и нахуй ты это говно советуешь? Рассинхрон будет, ебаный ты полудурок, блядь.
Android: Mobile Safari 115 2713100
>>713070
Ага, стекломойной пидорахе лучше знать.
image.png8 Кб, 986x34
Windows 10: Chromium based 116 2713112
Да походу av1 будет как и vp9 только в ютубе пользоваться таким темпами.
А hevc уже захватывает сердца.
Linux: Firefox based 117 2713118
>>713112
Так имплементаций пока нет, и ускорение тонет. Если начнёт жать хотя бы 0,5 fps, тогда и появятся рипы.
Хевку тоже не один год понадобился.
Linux: Firefox based 118 2713170
>>713112

Так а чё ты хочешь?

>libx265 slow 320k (55s)


>libvpx-vp9 320k (3m)


Ты думаешь кто-то будет ждать кодека, который загружает 4 потока по дефолту, в то время как x265 загружает их все, как это было еще с x264. Да и знающему x264 проще освоить x265 чем libvpx-vp9.
Linux: Firefox based 119 2713174
>>713112
ты забыл про двач с его webm-ками
sshot-001.png771 Кб, 1920x1080
Windows 10: Firefox based 120 2713352
>>686610 (OP)
Как можно было такую хуйню в продакшен пускать? Ёбаный стыд.
Windows 10: Firefox based 121 2713359
>>713352
Я, к слову, о кодеке, потому что только их VP и ублюдочный WebP Lossy так хуёво работает с градиентами.
1578007922723.jpeg5 Кб, 259x194
Android: Mobile Safari 122 2713420
>>713352
Ты как блядь рубашку снял? Уноси своего скриптонита и таблетки прими.
Windows 10: Chromium based 123 2713471
>>713352
Битрейта небось не хватило, открой mp4 версию и там посмотри
8bitissue.png124 Кб, 1000x1000
Linux: Firefox based 124 2713635
>>713352
Ну а чего вы хотели от 8-битного lossy кодека?
Начнем с того что 8 бит на канал недостаточно для отображения всех различимых оттенков даже человеческим глазом. Для сглаживания градиентов применяют костыль, который называется дизеринг. Дизеринг это подмешивание шума с минимально возможной для данной разрядности амплитудой, который создает субъективное ощущение большей разрядности.
Lossy кодеки ориентируются на сохранение деталей с большой амплитудой. ВЧ с малой амплитудой отбрасываются квантователем, то есть этот ваш дизеринг идет по пизде.
Linux: Firefox based 125 2713637
>>713635
Двач, что с тобой не так?
Как можно было так распидорасить thumbnail?
.png3 Кб, 500x100
Windows 7: Firefox based 126 2713820
>>713637
Чёрно-белые пнг с альфой коряво обрабатываются.
Windows 10: Chromium based 127 2714125
>>713635

>Lossy кодеки ориентируются на сохранение деталей с большой амплитудой. ВЧ с малой амплитудой отбрасываются квантователем, то есть этот ваш дизеринг идет по пизде.


В этом и пиздец. Кто в 2020 устраняет избыточность путём выпиливания ВЧ?
Linux: Firefox based 128 2714190
>>714125

>jpeg живее всех живых


>практически все видеокодеки все еще занимаются DCT преобразованием, устраняют избыточность путём выпиливания ВЧ и блочат при нехватке битрейта


>адекватной замены гифкам нет до сих пор


>что-то спрашивать про 2020-й год

Windows 10: Chromium based 129 2714213
>>714190

> деды фильтровали и ты фильтруй


так и победим
Linux: Firefox based 130 2714230
так то фотокамеры шумят достаточно сильно что-бы при сохранении в jpeg не заморачиватся с дизерингом.
А вот для рендеров и фотошопов нужен формат с разрядностью побольше.
shrek.webm8 Мб, webm,
128x72, 90:04
Linux: Firefox based 131 2714826
Шрек в 8 метров.
Неизвестно: Safari 132 2714902
>>714826

>128x72


убей себя.
изображение.png862 Кб, 1000x664
Linux: Firefox based 133 2714940
>>714826

> Video: av1 (Main), yuv420p(tv), 128x72, SAR 1:1 DAR 16:9, 4 fps, 4 tbr, 1k tbn, 1k tbc (default)


> Stream #0:1: Audio: opus, 48000 Hz, mono, fltp (default)

Неизвестно 134 2714947
>>714826
Чем на шиндофонах смотреть av1?
Неизвестно: Safari 135 2714948
>>714947
для воспроизведения этого говнокодека нужен суперкопьютер.
Неизвестно 136 2714952
>>714948
Мой шиндофон тот ещё суперкомпьютер. Но VLC увпшный, со старой либой, нет там av1.
Windows 7: Firefox based 137 2715030
>>714940
Опус не может в 44100.
Android: Mobile Safari 138 2715066
>>714826
For those curious I used the latest libaom git with a video bitrate of: 4.6kbps, 2 pass, cpu used 1, resized to 72p and 4fps. My audio bitrate was: 7.5kbps because anything less was headache inducing.
Linux: Firefox based 139 2715766
>>714948

>для воспроизведения этого говнокодека нужен суперкопьютер.


>CPU: Intel Core2 4300 @ 2x 1.8GHz


>libdav1d 0.5.2


>ffmpeg -c:v libdav1d -tilethreads 2 -i 'COSTA RICA IN 4K 60fps HDR (ULTRA HD)-LXb3EKWsInQ.mkv' -benchmark -f null -


144p

>frame= 3681 fps=288 q=-0.0 Lsize=N/A time=00:02:02.82 bitrate=N/A speed= 9.6x


240p

>frame= 9404 fps=111 q=-0.0 Lsize=N/A time=00:05:13.78 bitrate=N/A speed=3.72x


360p

>frame= 9404 fps= 65 q=-0.0 Lsize=N/A time=00:05:13.78 bitrate=N/A speed=2.17x


480p

>frame= 9404 fps= 39 q=-0.0 Lsize=N/A time=00:05:13.78 bitrate=N/A speed=1.31x



ffplay отказался воспроизводить av1 через libdav1d, поэтому применял костыли вида

>ffmpeg -c:v libdav1d -tilethreads 2 -i 'input.mkv' -vcodec yuv4 -acodec copy -f matroska - | ffplay -


До 360p воспроизводится нормально. На 480 есть тормоза (наверно из-за ремуксинга)

>frame= 2823 fps= 28 q=-0.0 Lsize= 1695013kB time=00:01:34.14 bitrate=147497.3kbits/s speed=0.929x

Apple Mac: Safari 140 2715781
>>715766
Лол 480р уже тормозит, а что там с 1080р или 4к? Даже на i7 будет тормозить. Пусть гугл себе в одно место засунет этот тормозной говнокодек.
Linux: Firefox based 141 2715794
>>715781
Видишь разницу между форматом видеокодека AV1 и декодером этого формата? libdav1d
Реализация гугла libaom-av1 декодит ещё хуже.

На i7 ничего не тормозит уже больше года, даже 4к.

> - libdav1d 0.1.0 73067e5


> libdav1d -threads 4 -tilethreads 4 - 58 fps 2.31x speed


https://forum.doom9.org/showthread.php?s=c9296846762f3daa7940cfa73d337f3d&p=1859793#post1859793
Android: Mobile Safari 142 2715827
>>715781

> гугл

Apple Mac: Safari 143 2715842
>>715794

>ничего не тормозит


>-threads 4


Достаточного одного ядра для воспроизведения vp9 4к, а для av1 нужно 4? Хочешь сказать, что это не говнокодек?
Linux: Firefox based 144 2715975
>>715842
Довольно логично, что для воспроизведения кодека из 2018 не годится камень десятилетней давности.
Неизвестно 145 2716008
>>715975
хитрые_лица_производителей_железа.png
1578481465552.jpeg14 Кб, 512x512
Android: Mobile Safari 146 2716033
>>716008
Ага, новый, требовательный к железу кодек для них как бальзам на душу. Уже предчувствую батхерт васянов с коре дуо, когда его начнут вводить повсеместно. Чому видево про танки логает??
Неизвестно 147 2716059
>>716033

>начнут вводить повсеместно


Пираты пользуется тем, что удобно для народа, а на остальное насрать.
Linux: Firefox based 148 2716069
>>716059
Ютуб отдаёт то, что ему выгодно.
А ему выгодно экономить на хранилище.
Неизвестно 149 2716074
>>716069
>>716059

>на остальное насрать

Linux: Firefox based 150 2716075
>>716074
Действительно, с чего это неуловимого джо должны волновать проблемы 90% оставшегося население
Linux: Firefox based 151 2716077
>>716069

>Ютубу так выгодно экономить на хранилище что кроме h264 + aac версий он еще кодирует и хранит vp9 версии и параллельно еще кодирует av1 для тестов.

Неизвестно 152 2716081
>>716075
Да, совершенно насрать на анальные сервисы.
Неизвестно 153 2716083
>>716077
Кстати, у некоторых старых видосов нет vp9 варианта.
Linux: Firefox based 154 2716088
>>716077
Основное гемор - в поддержке CDN сети, а там только самые ходовые форматы хранят.
Windows 10: Chromium based 155 2716094
>>715794
[libdav1d @ 0000016076c4a840] libdav1d 82eda83
Stream mapping:
Stream #0:0 -> #0:0 (av1 (libdav1d) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
Metadata:
encoder : Lavf58.35.101
Stream #0:0(eng): Video: wrapped_avframe, yuv420p, 3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc (default)
Metadata:
encoder : Lavc58.65.102 wrapped_avframe
frame= 3604 fps= 49 q=-0.0 Lsize=N/A time=00:02:24.16 bitrate=N/A speed=1.97x
video:1886kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=255.938s stime=8.812s rtime=73.274s
bench: maxrss=418548kB

Хуй знает вообще, в чём проблемы. 4к и ноутбучная затычка вместо проца.
Linux: Firefox based 156 2716102
>>686610 (OP)

> кодируем минутный ШебМ джва часа


Вся суть h265?
Неизвестно 157 2716103
>>716102

>Вся суть h265?


Вообще-то, h265 обычно пихают в матроску.
Linux: Firefox based 158 2716106
>>716103
И типо что? Быстрее кодирует?
Неизвестно 159 2716107
>>716106
Типо разные контейнеры, mkv и webm.
Неизвестно 160 2716113
>>713112
Хуевк захвати сердца уже лет 5 назад, если не больше
Неизвестно 161 2716114
>>716113
*Захватил
Неизвестно 162 2716115
>>713359
Кстати да, VP9 на ютубе ублюдошно с темной частью градиентов работает, артефачит ее на каадраты. Я правда не могу быть уверен, что контентмейкер загрузил не уже в таком качестве
Неизвестно 163 2716118
>>713635
8 бит на канал кстати с дитхерингом просто прекрасно выглядит, даже повышение до 10 бит на канал ничего не дает визуально. Тут видать YUV 8 бит, а не RGB 8 бит потому что
Неизвестно 164 2716123
>>716033
Да никто так-то не выпилит fallback на H.264, ибо афони
Неизвестно 165 2716124
>>716059
Ремухи UHD BD будут в том, в чем сами UHD BD, а это HEVC
Linux: Firefox based 166 2716128
2716118
Не знаю, какую разницу ты увидел между yuv444p и rgb.
Но вот yuv420p снижает разрешение цветовых в 2 раза по высоте и ширине, а потому сетчатый узор на цветовых каналах в yuv420p будет заметнее чем просто в RGB.

>даже повышение до 10 бит на канал ничего не дает


У тебя 10 битный монитор и сигнал с видеокарты? Если нет, то в лучшем случае ты увидишь дизеринг.
Неизвестно 167 2716138
>>716128

> Не знаю, какую разницу ты увидел между yuv444p и rgb.


Ну я не знаю на счет именно yuv444 - таких видосов раз-два и обчелся.

> У тебя 10 битный монитор и сигнал с видеокарты?


Да, и я с лупой проверял тестовый 10-битный пнг в мадвр. 8 бит с дитхерингом неотличимо от 10 бит с дитхерингом. Без дитхеринга да, легко отличимо.
Зеленый-Слоник.webm19,9 Мб, webm,
186x128, 87:05
Android: Mobile Safari 168 2716698
Культовый фильм теперь в 20мб!
Android: Mobile Safari 169 2716727
>>716698
Полтора часа в 20 мб! Я заинтересован. Можете пояснить залётному за все эти виды сжатия?
Android: Mobile Safari 170 2716764
>>716727
Современные кодеки и низкий битрейт: av1 - 20кб/с — видео и opus - 11кб/с — аудио. Ну и 16 часов кодирования.
Android: Mobile Safari 171 2716767
>>716764
*Кбит/с
Быстрофикс.
Неизвестно 172 2716834
>>716764
На N64 пригодилось бы при портировании Resident Evil 2
Android: Mobile Safari 173 2717547
Linux: Firefox based 174 2717783
>>716834
На N64 пригодились бы терафлопсы, чтобы av1 декодировать.
Неизвестно 175 2717890
>>717783
Хотя да))
Windows 7: UC Browser 176 2717954
а на русском конвертера для webm нема?
Linux: Chromium based 177 2717971
Как же хочеца HEIC, хоспаде.

Поигрался сейчас с HEIC через https://convertio.co/fr/ (Потому что мой Xn-Convert стабильно выплёвывает ошибку)

Оче круто.

Качественные изображения (пикрил 1) переводит практически без видимых потерь со значительным снижением веса.
Мусорные изображения (пикрил 3) также аккуратно переводит, но вес уже теряется просто пиздец как.

Оцениваю с точки зрения мемасной файлопомойки. так что требования небольшие - чтобы изображение на глаз осталось такое же, с градиентами (привет Webp Lossy) и цветами. Тут всё норм, различия ищу уткнувшись в экран, когда как с Webp всё было практически сразу видно - меня устраивает.

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

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

Еще бы AV1 пощупать...
1578766872869.png1,7 Мб, 1920x1357
Android: Mobile Safari 178 2717980
Сап, сжимач, возникла такая ситуация. Имеется жёсткий диск, который заполнен лоли хентаем уже чуть менее чем полностью файлами всевозможных типов и форматов. Реквестирую как лучше всего имеющееся файлы перекодировать и сжать для минимального размера при сохранении качества или его минимальных потерях.
И что почитать чтобы разобраться в этой теме?
Linux: Chromium based 179 2717984
>>717980

> при сохранении качества или его минимальных потерях.


This
https://css-ig.net/pingo

Настройки варьируются - lossless/небольшие потери/квадраты.
Android: Mobile Safari 180 2717995
>>717984
Но это ведь только для фото. А у меня кроме их там и видео, и аудио, и текст, и даже несколько программ в портативных изданиях.
Алсо я не против перековырять всё вручную. Софт из оп поста пойдёт под любые медиаформаты? Как кодировать?
Android: Mobile Safari 181 2718028
>>717995

> Софт из оп поста пойдёт под любые медиаформаты?


Да.
Видео кодируй с такими параметрами: -c:v libvpx-vp9 -b:v 0 -crf 32 -c:a libopus формат webm
Или такими: -c:v libx265 -crf 28 -c:a aac формат mp4
Аудио: -vn -c:a libopus -b:a 128k

> текст, и даже несколько программ в портативных изданиях.


7-zip
image.jpeg502 Кб, 2208x1242
Неизвестно 182 2718031
>>717971

> чтобы и на телефон скинуть


У меня обратная задача - как смотреть с телефона в старой версии АЦДЦее (которая еще не полным калом была) никак
Неизвестно 183 2718097
>>717995
>>717980
Медиа не сжимай, только текст, бинарники и подобное. Медиа и так в сжатом виде хранится, перекодируя не имея исходников ты просто получишь шакалов или ещё больший файл, в случае lossless. Всякие универсальные lossless алгоритмы, вроде lzma2, или даже жестокие алгоритмы семейства paq, поверх уже сжатых кодеками файлов дадут тебе парочку процентов.
Windows 10: Firefox based 184 2718248
>>717971
Ну, фиг знает.
По порядку:
png (6,43 МБ) -> heif (2,10 МБ) -> jpg (1,20 МБ).

Heif сохранял гимпом без потери качества.
Jpg c максимальным -quality 0 в ImageMagick.
Windows 10: Firefox based 185 2718253
>>718248
По качество/размер jpg, очевидно, сосет.
heif (313 КБ) -> jpg (318 КБ).

Оба с 50% качеством сконвертированы.
изображение.png147 Кб, 1903x892
Windows 10: Firefox based 186 2718257
>>718253
Webp (320 КБ) тоже.
Windows 10: Firefox based 187 2718261
>>718248
Про размер согласен. Кажется тот онлайн конвертер что-то мудрит. Позже пробовал переводить JPG в WebP и он каким-то образом выдавал результаты, которые были всегда меньше оригинала и при этом обработаны явно с помощью WebP Lossless, потому что характерных артефактов на градиентах не было.

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

Другими словами, как конвертер тот сайт очень хорош, но не объективен.

Еще, заметил, я думал, что это у меня из-за разницы вывода в гимпе и обычном картинкоменеджере - HEIC зеленит изображение, что довольно неприятно.
Windows 10: Firefox based 188 2718278
>>718261

>HEIC зеленит изображение, что довольно неприятно.


Кстати, да. Гимп зеленит на выводе.

ImageMagick и gimp в png.
Android: Mobile Safari 189 2718283
>>718028
>>718097
Спасибо.

> перекодируя не имея исходников


Какие исходники?
Android: Mobile Safari 190 2718309
>>718028
>>717995

> Аудио: -vn -c:a libopus -b:a 128k


Формат opus, забыл
Windows 7: New Opera 191 2718316
>>686610 (OP)

>джипег как образчик сжатия на 10 из 10 по шкале ебучих шакалов


>ко-ко-ко-ко-пок-пок-порЭЭЭЭЭк унижаем пээнгэблидей!!!



А?
Windows 10: Firefox based 192 2718332
Какой положняк по кодекам и софту?

av1 > h265 > vp9 > h264
opus > vorbis > aac > mp3
heif > webp > jp2 > jpg

ffmpeg для видео и аудио.
convert из ImageMagick для изображений, но heif только чтение.
Неизвестно 193 2718362
>>718283

>Какие исходники?


RAW, нетронутые кодеком данные с камеры или микрофона.
>>718309
>>718028
Порча информации.
Android: Mobile Safari 194 2718363
>>718362
Это ты создаёшь flac треды в /б?
Linux: Chromium based 195 2718364
>>718278
А, ну, если это чисто проблема GIMP'a, тогда формат хороший - одобряю.

Тогда положняк -
WebP Lossless - замена PNG.
HEIC/HEIF - замена JPG.

Ждём AV1
Linux: Chromium based 196 2718366
>>686650

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


На форчане до сих пор нет VP9 лол.
Linux: Firefox based 197 2718394
>>718332
aac строго лучше vorbis, vorbis имхо даже хуже mp3, но я накину ему за открытось
jp2 - маргинальщина, которой никогда не было
jpg и webp - примерно одного уровня, вопрос уровня "мыло или кубики", кому какие артефакты больше нравятся
avif очень потанцевальный формат, но в него вообще никто не умеет

>convert из ImageMagick


Говнокомбайн. Только специализированные енкодеры и оптимизаторы.
Linux: Firefox based 198 2718396
>>718362

>Порча информации.


Устранение избыточности.
Linux: Firefox based 199 2718437
>>717971

>Проблема лишь в том, что единственная программа, которая захотела его открыть это GIMP


Nomacs через костыли поддерживает, макос/шин10 умеет, последние мобилки в хейф по умолчания снимают.
Осталось только браузеры научить.
Неизвестно 200 2718440
>>718396
Избыточными будут только часы перекодировки.
Windows 10: Firefox based 201 2718462
>>718394

>Говнокомбайн


Удобно через консольку работать с нужными кодеками изображений. FFmpeg у тебя тоже говнокомбайн получается.

>>718437

>шин10 умеет


Там пздц, конечно.
В мсторе hevc/heic платный, а бесплатная версия только если железо поддерживает (мне повезло с этим). Открывается все это либо через стандартное "Фотографии" (или др софт из мстора), который мылит картинку. Либо через тормозные костыли в каком-нибудь xnviewmp открывать.

Самая большая проблема в низкой распространенности новых форматов в приложениях и закрытом коде.
Неизвестно 202 2718526
>>718394

> vorbis имхо даже хуже mp3


Неа
Android: Mobile Safari 203 2718555
Можете нормально пояснить несведующему анону про все эти ваши форматы и кодировки? Я сейчас вижу эту картину примерно так:
Фото
JPEG - качество средней паршивости, при сжатии шакалится
PNG - лучше чем предыдущий, но и места отжирает больше
WEBP - тот же джейпег, но меньше по размеру и сжимаясь размывается
HEIF - НЁХ, скорее всего замена пнг
Видео
Тут нихуя непонятно, но webm>>mp4
Кодеки
В этом тёмном лесу нихуя не ясно.
Аудио
MP3 - для лохов
OPUS - выбор мастеров
Неизвестно 204 2718560
>>718555

> Фото


> JPEG - качество средней паршивости, при сжатии шакалится


Самое худшее качество

> PNG - лучше чем предыдущий, но и места отжирает больше


Идеальное качество, места естессно зрет стоко, скоко надо

> WEBP - тот же джейпег, но меньше по размеру и сжимаясь размывается


> HEIF - НЁХ, скорее всего замена пнг


Замена джейпегу, но бровзерами не поддерживается, так что на самом деле не замена

> Видео


> Тут нихуя непонятно, но webm>>mp4


Это контейнеры, а не алгоритмы сжатия

> Кодеки


> В этом тёмном лесу нихуя не ясно.


> Аудио


> MP3 - для лохов


> OPUS - выбор мастеров


Всё так
Неизвестно 205 2718565
>>718560
А видео примерно так, от плохого к хорошему:
MJPEG (в PS1 юзалось)
MPEG2
DivX
H.264/VC1
HEVC/VP9
AV1
Linux: Chromium based 206 2718571
>>718560
Стоит отметить, что у WebP есть два типа сжатия - lossy и lossless (с потерями и без потерь соответственно).

WebP lossless подходит как охуенная замена png, поскольку абсолютно ничего не теряет, а размер ~на 20% меньше.

WebP lossy - ну такоооое. Вроде как замена jpg, но нужно пердолить конвертер ключами, чтобы получить нормальное изображение. HEIC в этом плане будет лучше, но он проприетарный, а значит дальше айфончиков особо не пойдет. Ждём внедрения AVIF.
Linux: Chromium based 207 2718576
К слову, почитал документацию cwebp и поэкспериментировал с ключами и вывел универсальную команду для перевода картинокомойки_jpg в картинкопомойку_webp (для png лучше всё же использовать lossless)

cwebp вход.jpg -sharp_yuv -jpeg_like -af -mt -sns 100 -o выход.webp

>-sharp_yuv


Самое важное и нужное. Замечал, что часто после перевода некоторые цвета теряют свою силу и сочность, что для меня лично не приемлемо в принципе. Это команда оставляет видимую палитру неизменной.

>-jpeg_like


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

>-af


Автоматическая фильтрация - удаляет мелкие шероховатости после перекодировки.

>-mt


Мультипоточность

>-sns 100


Оставляет большую детализацию изображению совершенно не прибавляя в весе.

Сравнивал выход с ключом/без с максимальными/минимальными свойствами (-sns 100/-sns0) и итоговые ключи выдавали самую качественную картинку на мой взгляд.

В целом получается +- оригинальное качество, но намного меньший вес. Из минусов - большее время перекодировки, но не особо заметно на изображениях до двух мегабайт.

Дополнения приветсвуются.
Linux: Firefox based 208 2718633
>>718576

> перевода картинокомойки_jpg в картинкопомойку_webp


дважды пережимать с потерями? во сколько раз выигрыш в весе не написал даже.
Linux: Firefox based 209 2718698
>>718560

>webp


>но бровзерами не поддерживается


Что значит не поддерживается?
https://caniuse.com/#feat=webp
Ничего что не поддерживают только ишак и сафари. А про KaiOS Browser кто нибудь вообще слышал?
Android: Mobile Safari 210 2718745
>>718698

>про KaiOS Browser


Очередная швободная поделка, как и всё швободное ПО и ОС - говно
Windows 7: Firefox based 211 2718751
Два .bmp шакалам в треде.
Linux: Chromium based 212 2718772
>>718633
Да, это я что-то на радостях написал от того, что удалось избавится от ужасных градиентов, но всё равно достаточно много деталей мылится, с HEIC'ом вообще не конкурент.

Вот окончательная команда, что получить картинку сравнимой или меньше по весу с оригинальной jpg с приемлимым качеством:
cwebp "$1" -sharp_yuv -jpeg_like -af -mt -sns 100 -q 90 -m 6 -o $1.webp

Конвертировать всю файлопомойку я не стал, подожду AVIF или HEIC.

По весу примерно:

1.jpeg - 17 кб
1.webp 13.5 кб

2.jpeg - 1 миб
2.webp 317 кб
Linux: Chromium based 213 2718773
>>718772
Оригиналы
Linux: Chromium based 214 2718775
>>718772
При этом довольно интересный эффект наблюдатся - на маленьких зашакаленных jpg webp наоборот делает лучше, убирая своим мылом мусорные квадраты png. собсна первые два пика релейтед.
Linux: Firefox based 215 2718777
>>718772

> Конвертировать всю файлопомойку я не стал, подожду AVIF или HEIC.


через 10 лет еще что-то запилят, будешь третий раз её сжимать
Linux: Chromium based 216 2718780

>мусорные квадраты png


jpg разумеется. Надо идти спать.
Неизвестно 217 2718783
>>718571
У пнг, имей ввиду, размер зависит от проги, сохраняющей его. В фотошопке самым маленьким получается
Неизвестно 218 2718784
>>718698
Не-не, я это знаю, я токо про хеик писал, вебп предыдущей строкой при копировании просто осталось
Неизвестно 219 2718785
>>718772
Хех первая в вебп даже лучше стала))
Неизвестно 220 2718786
>>718775
Ага))
Android: Mobile Safari 221 2720254
Поясните за FLAC и MKV
Windows 10: Firefox based 222 2720352
>>720254
FLAC - пожатие аудио без потерь (lossless). Избыточен для 99% слушателей и только для отбитых аудиофилов.
MKV - контейнер, куда удобно запихать кучу дорожек аудио/субтитров. Развит в webm.
Неизвестно 223 2720368
>>720352

> Избыточен


>750 Кбит/с


>при жестких дисках 8 ТБ (66280 лет FLAC музыки)

Неизвестно 224 2720369
>>720352
Алсо

> только для отбитых аудиофилов.


>16 бит


>44,1 КГц


>2 канала

whosedog.jpg52 Кб, 1607x956
Linux: Firefox based 225 2720377
Вы знаете, что miro-video-converter (https://github.com/pculture/mirovideoconverter3) очень круто сжимает!? И ещё вопрос, что это за порода собак?
Linux: Firefox based 226 2720379
>>720368

>66280


Чёт не видел тилибонов с 8Тб.
Неизвестно 227 2720380
>>720377
Мне кажется эта собака сгенерирована нейросетью
I like you pony.webm362 Кб, webm,
640x356, 0:03
Linux: Firefox based 228 2720382
>>720380
Когда кажется, нужно снизить дозу, если бы ты знал породу, то и не стал отвечать вопросом на ответ...
Неизвестно 229 2720393
>>720377

>шкурка для ффмпег


>очень круто сжимает


>последний коммит 7 лет назад


Уникальный софт, достоин уровня /s.
mendellian.webm7,5 Мб, webm
Windows 10: Firefox based 230 2720400
А вообще самый крутой формат сжатия музла - трекерный лол. Типа .mod, .it, .xm, .s3m. Вот этот трек например в оригинале меньше 400 килобайт весит. Но есть нюанс...
Windows 10: Firefox based 231 2720407
Что там по ОПУСУ кстати слышно? Никаких обнов с апреля прошлого года. Всё, кодек уже допилили до идеала, ничего фиксить не надо?
Неизвестно 232 2720409
>>720400
В трекерных очень всегда сухое звучание, без сложных ревербаций, мне не нравится, скушно такое слушать
Windows 10: Firefox based 233 2720421
>>720409
Ну возьми "мокрые" семплы, в чем сложность? А ведь прикольная идея - кодировать исходный файл не сжатием, а реально конструированием и программированием, раскладывая его на семплы и скриптуя. Чтобы не человек в трекере сразу семплы набивал, а прога из стомегабайтной вавки сделала .mod на 300кб, неотличимый по звучанию от оригинала. Но для похожей хуйни наверно такие вычислительные мощности понадобятся, буквально суперкомп с ИИ. И один файл будет кодироваться сутки.
Скажи-ка брат аудиофил.webm1,3 Мб, webm,
1270x1080, 1:31
Android: Mobile Safari 234 2720430
Снимок экрана от 2020-01-15 21-53-04.png21 Кб, 490x660
Linux: Firefox based 235 2720464
>>720393
Ну в Линукс это гуи и удобноя менюшка.
Неизвестно 236 2720492
>>720421
Да, норм идея
Linux: Firefox based 237 2720504
>>720464
Сойдёт для вкатывания новичков. Но для профи это НЕНУЖНО.
Windows 10: Firefox based 238 2720512
>>720352
Не избыточен, если нужно кодировать потом.
Linux: Firefox based 239 2720526
>>720512

>если нужно кодировать потом


Это студийный юскейс. Флак в бытовом прослушивании никому не всрался.
Неизвестно 240 2720536
>>720464
В гну/линуксе почти на всё есть мокрописька на гтк, мокрописька на кьюте и мокрописька на нкурсес.
Linux: Firefox based 241 2720559
>>720536
и мокрописченый биндинг на питоне
Неизвестно 242 2720587
>>720559
И аналог на расте и го.
Screenshot20200117110543.png15 Кб, 475x130
Linux: Chromium based 243 2721593
Посоны, что выбирать в такой ситуации кроме очевидного flac?
Windows 8: Chromium based 244 2721596
Linux: Firefox based 245 2721660
>>721593
выбирай aac
Разницы в звучании все равно не заметишь, зато места сэкономишь
Linux: Firefox based 246 2721678
>>721593
Я сейчас выбираю для скачивания mp3. Потому что по дефолту сейчас везде стриминг пашет. А в нестандартных местах у mp3 выше всего шансы быть проигранными.
Linux: Firefox based 247 2722173
Windows 7: Firefox based 248 2722245
>>721678
Долго расшифровывал твой пост, а потом понял что ты просто зумерок со стримингом вместо hdd. Так зачем тебе вообще выбирать аудиокодек из раздач торрента?
Android: Mobile Safari 249 2722252
Какой формат сферически и в вакууме является лучшим для анимаций?
Неизвестно 250 2722257
>>722252
Самый крутой наверное - AV1
Android: Mobile Safari 251 2722359
>>722257

> AV1


Это же ведь видеоформат, а я говорю про растровую 2д анимацию gif, apng...
Windows 7: Firefox based 252 2722366
>>722359
avif соответсвенно
Windows 7: Firefox based 253 2722368
>>722359
а вообще вектор, а также векторные анимации это топ
Linux: Firefox based 254 2722378
>>722368

> вектор, а также векторные анимации это топ


Только вот приличных форматов векторной анимации нет со времён почившего флеша.
Неизвестно 255 2722383
>>722359
А, я думал про анимэ
Apple Mac: Safari 256 2722429
>>722378
svg же можно анимировать
изображение.png355 Кб, 1024x649
Linux: Firefox based 257 2722440
>>722429
Можно, только через жопу.
Потому мы ни масяни, ни древесных друзей в свг не видим.
Linux: Firefox based 258 2723014
>>722245

>стримингом вместо hdd


Как что-то плохое. Цивилизация даёт блага - пользуйся. Нет хотим газку поддавать.
Windows 7: Chromium based 259 2723110
>>718462

> FFmpeg у тебя тоже говнокомбай получается


Что значит получается? Всегда им был и остается.
Linux: Firefox based 260 2723158
>>722440

>только через жопу


Поясни. Я видел люди пилили анимации, выглядело хорошо.
Неизвестно 261 2723243
>>723110

>Что значит получается? Всегда им был и остается.


А вот тут ты обосрался. Он модульный, перед компиляцией можно выбрать нужный функционал и исключить лишнее.
Android: Mobile Safari 262 2723859
>>716083
Тому шо оригиналов уже нет, а повторно шакалить из мп4 будет совсем пиздец
Android: Mobile Safari 263 2724708
Какой формат самый эффективный для хранения документов? На форматирование строго похуй.
.txt или .md?
Неизвестно 264 2724717
>>724708
Обычный ASCII файл, на расширение похер.
изображение.png8 Кб, 434x186
Windows 10: Firefox based 265 2724803
>>724717
Текстового формата с сжатием еще не придумали что ли?
15796037809450.jpg17 Кб, 320x276
Linux: Firefox based 266 2724813
Неизвестно 267 2724820
>>724803
Зачем, когда обычный ASCII файл открывается практически на любой системе очень большим количеством программ.
изображение.png18 Кб, 980x238
Windows 10: Firefox based 268 2724824
>>724820
Хочется сферического пожатия в вакууме. Экономия места и с нынешними мощностями мгновенно все будет с каким-нибудь открытым методом с хорошими место/скорость показателями. Ясен пень не паком, эти 22Мб 17мин жались.
>>724813
Там все очень плохо.
Неизвестно 269 2724826
>>724824

>Там все очень плохо.


С хуя ли?
Неизвестно 270 2724828
>>724824

>Хочется сферического пожатия в вакууме. Экономия места и с нынешними мощностями мгновенно все будет с каким-нибудь открытым методом с хорошими место/скорость показателями. Ясен пень не паком, эти 22Мб 17мин жались.


Запили раздел на бтрфс со сжатием zstd.
Android: Mobile Safari 271 2726434
Windows 10: Firefox based 272 2731217
Можно в ffmpeg как-нибудь предсказать размер, исходя из параметров и соуса, видео до ожидания 100500 часов кодирования?
Неизвестно: Safari 273 2731436
>>731217
зависит от формата, но в случае h264/h265 работает такая формула
((bv + ba) * t) / 8192
bv - битрейт видео (bps)
ba - битрейт аудио (bps)
t - продолжительность видео (s)
Windows 10: Firefox based 274 2731555
>>731436
Спасибо. Но битрейт видео какой вписывать, если он постоянно прыгает?

А для vp9 есть что-нибудь подобное? Приходится с разными -crf в 3-4 потока одновременно запускать кодирование того же видео (все равно vp9 не полностью проц нагружает, как h264).

Алсо, тут пробовал сравнить гпу кодирование с h264_nvenc и обычный h264, но получаются совершенно разные результаты с командами, отличающимися только этими кодеками.
1.jpeg325 Кб, 800x800
Linux: Firefox based 275 2731916
>>686610 (OP)
Аноны, как сжимать аудио через libvorbis, чтобы конечный файл был без видеопотока? Сжимаю коммандой:
ffmpeg -i 1.m4a -c:a libvorbis -q:a 0 1.ogg
но почему-то на телефоне открывается, как видео. Как исправить?
Linux: Firefox based 276 2731924
>>731916
Я ебан. Нужно ставить флаг '-vn', чтобы отключить видеопоток.
Windows 10: Chromium based 277 2731948
>>686610 (OP)
Не уверен, правильный ли тред, но ладно.
Монтирую видео (оригинал в H265) в премьере и превьюха в премьере жестко тормозит на i7 2600, что аж невозможно. В всмысле, на ноутбуке ryzen 3700u она меньше тормозит, хотя ноутбук очевидно слабее.
Windows 10: Chromium based 278 2731953
>>731948
Дополню, что на ноуте ссд, а на компе проект находится на хдд, может ли это как-то влиять?
Windows 10: Chromium based 279 2731983
>>731948

>H265


>i7 2600


Ну ты пони. Во-первых, да, SSD может влиять. Во-вторых, 2700k, при всём уважении к Sandy Bridge, монтаж h.265 просто не тащит, как бы ни было горько это признавать.
Android: Mobile Safari 280 2731996
>>731983
Жалко. Все-таки удивительно, что ноутбучный процессор 4/8 на 15 ватт справляется лучше, чем десктопный 4/8 большей частоты на 90 ватт.
Android: Mobile Safari 281 2732006
>>731996
Ничего удивительного. У кукурузера, емнип, аппаратная поддержка декодирования h.265. Годы никого не щадят.
Apple GayPhone: Safari 282 2732010
Да
Android: Mobile Safari 283 2732011
>>732010
Пизда
Android: Mobile Safari 284 2732022
>>723859
а куда оригиналы делись? экспорт данных гугла выдаёт оригиналы, как минимум 8-летние оригиналы ещё целы
Android: Mobile Safari 285 2734617
Не тонем
29249224d0515af9ad7c81b7dc3e7c3c.jpg84 Кб, 1280x720
Windows 10: Chromium based 286 2737331
Стандарт AVIF вроде окончательно принят, а никакой софт до сих пор в него не умеет или я плохо искал? Особенно интересно насколько лучше lossless сжатие в сравнении с webp
Linux: Firefox based 287 2737361
>>737331

> софт до сих пор в него не умеет


Это. Только очень эпизодические звери.

>lossless сжатие


Все новые форматы фокусируются вокруг удаления избыточности. Нечё от них лослесс побед ждать. Юзай специализированный flif.
Windows 10: Chromium based 288 2737434
>>737361
А где же поддержка всеми мировыми корпорациями, где же попенсорс с гитхаб-бинарниками от васянов...

>FLIF


У меня не взлетел, при конвертации полноэкранных пнг скриншотов во флиф файлы в основном были немного больше чем вебп лосслес. Последний к тому же быстрее открывается и имеет превьюшки в проводнике дриснятки. Для перегона юзал XnConvert, возможно там не те либы и можно получить результат получше
Windows 10: Chromium based 289 2738198
>>737331

>или я плохо искал?


https://github.com/AOMediaCodec/av1-avif/wiki
пока мало что, да и то не всегда нормально работает, можно еще руками через Aomenc сжимать и потом муксить MP4Box

>Особенно интересно насколько лучше lossless сжатие в сравнении с webp


https://www.reddit.com/r/AV1/comments/aabqdc/lossless_compression_test_png_vs_webp_vs_avif/
когда то давно еще тестировали энтузиасты, но тут тоже много лишних действий нужно совершать для подачи кодировщику в нормальный для него вид и формат, вот табличка для примера
https://docs.google.com/spreadsheets/d/1bG-CSTn_L79MtS7A-wR572H5_W_3kb2xX5AWagKn1ak/edit#gid=0

>Юзай специализированный FLIF


Его автор уже пару лет помогает делать Jpeg XL и влил туда свои основные наработки с FLIF и позже его же FUIF, так что сразу лучше на него и смотреть https://gitlab.com/wg1/jpeg-xl
Последние билды под винду на doom9 обычно выкладывают:
https://forum.doom9.org/showthread.php?p=1901676#post1901676
Для lossless у него нужно выставлять качество 100 (-q 100), также он может пережимать Jpeg без потерь, в среднем на 22% (принятый в формат brunsli), можно глянуть онлайн, как это пашет - https://google.github.io/brunsli/
Android: Mobile Safari 290 2739944
Зачем аноны хотят перекодировать свои паки с трапами в новый формат, если при каждом перекодировании качество ухудшается?
Windows 10: Palemoon 291 2739945
>>739944
Потому что аноны идиоты.
Windows 10: Microsoft Edge 292 2740170
Ничего не понимаю в этих шакалах.
Возможно на одном и том же видеотреке некоторую часть выполнить с большим качеством? Например, есть ролик с записью от видеорегистратора, где не очень важен некоторый тайминг перед аварийной ситуацией, но нужен для общей ситуации, а в некоторый момент качество увеличивается.
Android: Mobile Safari 293 2740185
Как сделать чтобы youtube-dl скачивал bestaudio и bestvideo, а потом ffmpeg склеивал это все в mp4/webm. а то у меня все в mkv склеивается
Windows 7: Firefox based 294 2740227
>>740185
--merge-output-format
Android: Mobile Safari 295 2740263
>>740227
thx, anon
Android: Mobile Safari 296 2740379
>>740170
Делить на части, кодировать, склеивать.
1582574940270.jpg113 Кб, 824x662
Windows 10: Palemoon 297 2740384
>>740170
--zones в x264
У ffmpeg можно квантование на лету менять, но я не помню как, слишком давно это было.
1582584728092.PNG48 Кб, 2284x342
Windows 10: Palemoon 298 2740473
>>740384
>>740170

> У ffmpeg можно квантование на лету менять


Возможно вот это, но кажется другая команда была, это возможно старая команда, которую заменили.
Windows 10: Firefox based 299 2741186
>>686610 (OP)

> WebP


Сорта жипега от гугла. Выглядит как говно по сравнению с BPG.
Linux: Firefox based 300 2741191
>>741186

>с BPG


BPG - мертворождён, можешь забыть про него.
Вместо него, с лёгкой руки эппла, пришёл по сути тот же HEIF.
И конечно же WebP проигрывает HEIF во многом. Во многом, кроме распространённости и поддержки в ПО.
Windows 10: Firefox based 301 2741201
>>741191

>BPG - мертворождён


Так-то WebP тоже. К тому времени когда его поддержку добавят везде и им даже начнут пользоваться люди он станет ненужен из-за ширины канала и возможностей железа юзать повсеместно PNG, а аппаратная поддержка JPG с его производными типа JPEG XR, JPEG-LS и JPEG2000 делают жопег и вовсе неубиваемым в обозримом будущем, это говно не утонет, прост в настройках шакалирование будут меньше пользовать. WebP мертворождённое говно, в попытке "пожать" сделали говнище, которое в затратах процессорного времени соревнуется с полноценными lossles (и обгоняет их), при этом ещё и качества не даёт.
Windows 10: Firefox based 302 2741205
>>731948

>Монтирую видео (оригинал в H265) в премьере и превьюха в премьере жестко тормозит на i7 2600, что аж невозможно. В всмысле, на ноутбуке ryzen 3700u она меньше тормозит, хотя ноутбук очевидно слабее.


Даже без учёта того, что у 3700u аппаратная поддержка H265 в видеоядре, он на клыка сэндику даёт. Там блядь оперативная память в два раза почти шустрее, инструкции новые и старый Гипертрединг времён Сэндика на фоне Скалейковского и Рузеновского гипертреда это говно.
Apple Mac: Safari 303 2741207
Я сжал.
Linux: Firefox based 304 2741219
>>741201

>К тому времени когда его поддержку добавят везде


Она сегодня и есть практически везде.

>поддержка JPG с его производными типа JPEG XR, JPEG-LS и JPEG2000


А вот у этих нет и никогда не появится. Вот и вся история.
изображение.png11 Кб, 846x111
Windows 10: Firefox based 305 2741223
>>741219

>Она сегодня и есть практически везде.


1. Если бы работал в веб макакинге, то знал бы, что он практически нигде не используется.
2. Я больше скажу, сам гугл в рот ебал свой WebP, используя исключительно SVG, PNG и JPG на своих сервисах, проще говоря, WebP не нужен даже Гулагу. Вот тебе пруф, можешь сам отинспектировать сервисы гугла, везде svg и png.
3. А теперь самое смешное, основное применение WebP по состоянию на 2020 год это пережатие уже уебански шакальных jpg с сайтов для онлайн конвертации и отдаче юзеру через CDN.
4. Apple Safari.
Apple Mac: Firefox based 306 2741226
>>741223

> сам гугл в рот ебал свой WebP


Он его для юзер-контента использует, превьюшки на ютубе, картинки/иконки в плейсторе
изображение.png10 Кб, 752x106
Windows 10: Firefox based 307 2741227
>>741226

>превьюшки на ютубе


Лол, нет.

>картинки/иконки в плейсторе


Иконки - да. Часть картинки обложки, наложения кнопок плей и т.п. png.
1492001401509.png122 Кб, 868x210
Apple Mac: Firefox based 308 2741228
Linux: Firefox based 309 2741231
>>741223
Яндекс отдаёт предпросмотр картинок в webp, например.
1552093425893.png79 Кб, 368x442
Apple Mac: Firefox based 310 2741233
>>741227
А в плейсторе он оказывается отдает хрому вебп, а лисе пнг. Хотя с тем что вебп нинужен я согласен.
Windows 10: Palemoon 311 2741300
>>741205

> Гипертрединг времён Сэндика на фоне Скалейковского


А что изменилось? По сравнению с смт все такое же сендиговно.
Windows 7: Firefox based 312 2749525
Для avif теперь выкладывают билды под винду, плюс завезли поддержку png https://ci.appveyor.com/project/louquillio/libavif/build/artifacts
Windows 7: Chromium based 313 2749614
Анон в /a/ помню год назад скидывал Evangelion 1.11 влезающий в 40 Mb двача, и при этом это можно было даже смотреть, фильм на полтора часа. Есть у кого этот файл?
Windows 7: Chromium based 314 2749621
>>749614
Помню, что ширина кадра была аж 350
Linux: Firefox based 315 2749772
Что то странное происходит с 251-м opus на youtube.
Как то раз, загрузил на youtube flac, он его тогда пережал в aac, ну ничего особенного от этого формата я и не ожидал. Потом я забыл про то видео и пережал для себя тот флак в opus vbr 144k.
Теперь youtube кодирует vp9/opus версии. И на том видео тоже появилась opus версия. Ну думаю, ща посмотрю на спектры со всеми 20 килогерцами. Ага, щас! Ютуб их зачемто взял и порезал. Этот срез похож на mp3, но нехарактерный для opus. Те остатки которые видны на спектрограмме можно списать на недоработку lowpass фильтра.
Главный вопрос: Зачем? Зачем они приравняли частотный диапазон к aac версии трека? Это они так пытаются продвигать свои сервисы "Youtube music" или "Google Play Music"?
Linux: Firefox based 316 2749773
>>749772

>144kbps

1584048587336.jpg35 Кб, 600x505
Windows 10: Palemoon 317 2749779
Linux: Firefox based 318 2749781
>>749779
Ростелеком.
А почему вы спрашиваете?
Windows 10: Chromium based 319 2755831
Новый XnView MP с версии 0.96 читает/конвертирует AVIF.
Linux: Firefox based 320 2755947
>>755831
Только он разожрался как не в себя. Подожду пока в nomcas впилят.
Windows 10: Chromium based 321 2756223
>>755947
Куда? В nomacs?
Linux: Firefox based 322 2756280
А есть для опуса какие-нибудь костыли, которые анализируют mp3шный трек и исходя из его битрейта, частот и энтропии сами выбирают пресет для сжатия типа "чтоб примерно так же осталось"?
Windows 10: Firefox based 323 2756288
>>755947

>nomcas


Тормозное говно какое-то. Хотя, это на винде, может быть.
Неизвестно 324 2756296
>>749772

> Те остатки которые видны на спектрограмме можно списать на недоработку lowpass фильтра.


Нет, они похожи именно на мр3 стайл оставление только самых громких пиков свыше 16 КГц
Неизвестно 325 2756297
>>756280
Нахуй надо?
Linux: Firefox based 326 2756354
>>756297
Чтобы пережимать звукан из mp3 в opus, внезапно.
Неизвестно 327 2756375
>>756354
А в чем планируемая польза от этого?
Linux: Firefox based 328 2756376
>>756375
Чтобы итоговый файл занимал меньше места, вестимо.
Неизвестно 329 2756387
>>756376
Хех, мда. А не лучше будет скачать желаемый музон в флак, а потом пережать в опус желаемого битрейта? Избежишь двойной потери качества
Linux: Firefox based 330 2756395
>>756387
Почему ты решил что это музыка, и что она существует в каком-то другом экземпляре? Двач ты не меняешься.
Это архивные записи разговоров, при том в огромном количестве, из разных источников и с разным качеством.
Я конечно могу засесть на две недели со слепым тестированием и подбором битрейта. Но хочется один такой ключик типа -mp3_like как тут >>718772 который примерно оставит всё как есть, но позволит занимать меньше места.
Linux: Firefox based 331 2756488
>>756296
lowpass фильтры не идеальны, и при громких пиках они оставляют мусор в спектре они не полностью их подавляют, так что они остаются в спектре с приглушенной амплитудой.
В принципе, их можно подавить средствами самого кодировщика, путем подбора квантователя для соответсвующей полосы частот так, что-бы этот мусор остался за порогом округления, но qaac почему-то этого не сделал.
А opus еще на 32-х килобитах в секунду пытается закодировать весь диапазон. А поскольку после lowpass фильтр не идеален и оставил после себя мусор, то opus взял и закодировал его как смог.
Для примера 2-й пикрелейтед mp3 320kbps. Здесь видно что спектр отфильтрован, но оставшийся сигнал имеет примерно ту-же громкость мощность, энергия, как оно правильно называется?, что и сигнал с другой полосы частот. Это и отличает фильтр в mp3 от просто lowpass фильтра.
А теперь снова посмотри на ту спектрограмму ютубовского опуса. Там сигнал в самой высокочастотной полосе частот тише основного спектра, что является признаком применения именно lowpass фильтра перед кодированием, а не фильтрации высокобитрейтного mp3.
Linux: Firefox based 332 2756505
>>756280
>>756354

>пресет для сжатия типа "чтоб примерно так же осталось"


>mp3 в opus


Ты видимо не шаришь. MP3 и Opus это совершенно разные кодеки. У них общего только то что это lossy аудио кодеки.
Ты пробовал сравнивать AAC LC с HE-AAC (тот который с SBR)? Должно быть очевидно, что высокие частоты синтезированные из низких при той коррекции что там имеется не будет идентичным спектру AAC LC с более высоким битрейтом.
Начнем с того что opus произошел от аудиокодека Vorbis, очередного убийцы mp3, отличается патентной независимостью. Говорят, у него математика преобразования другая. А потому, ты не можешь запихнуть mp3 в Vorbis, только lossy перекодирование.
Opus же скорее ответ AAC, нежели MP3. И раз он выиграл в аудиофильских слепых тестах в 64kbps у HE-AAC, вероятно, у него есть нечто похожее на SBR, а именно: Band Folding. А потому, opus может тебе закодировать Full Band даже на 32 килобита в секунду (но криво, со слышимыми артефактами сжатия), а может даже меньше.

Подбор пресетов опуса под MP3 здесь не уместен, поскольку OPUS не режет частоты так, как это делает MP3. Это ты можешь делать на AAC LC или на Vorbis.

Единственный вариант юзать opus это конвертировать из lossless, или в крайнем случае MP3 CBR 320 kbps.
Неизвестно 333 2756559
>>756488

> lowpass фильтры не идеальны


Цифровые - идеальны)

> А opus еще на 32-х килобитах в секунду пытается закодировать весь диапазон


Ну он даже на 144 кбит/с на ютубе режет под 20 КГц (по моим тестам в фирефох-треде) (притом полный диапазон - 24 КГц)

> посмотри на ту спектрограмму ютубовского опуса. Там сигнал в самой высокочастотной полосе частот тише основного спектра, что является признаком применения именно lowpass фильтра перед кодированием, а не фильтрации высокобитрейтного mp3.


Хотя да, но ослабление громкости слишком слабое
Windows 10: Chromium based 334 2756561
>>686610 (OP)
Хули толку. Большинство этих форматов здохнет, как и все технически более совершенные «убийцы» mp3, jpg, rar и т.д. Популярность и распространённость — вот что действительно важно.
Всем этим 7zip-ам, опусам и прочему jpeg2000 вечно ютиться на задворках интернетов, поддерживаемые на искусственной вентиляции лёгких силами трёх с половиной задротов. Мне, разумеется, тоже не нравится эта ситуация, когда привычка стоит на пути прогресса, но хули делать.
Linux: Firefox based 335 2756564
>>756561

>Популярность и распространённость — вот что действительно важно.


heif - дефолтный формат айфонов, поддерживается практически всеми ОС. Как только браузеры научатся - вот тебе и наступит новый жипег.
Linux: Firefox based 336 2756568
>>756564
HEVC не поддерживают принципиально. А HEIF, обертку под HEVC для картинок, значит поддержат?
Windows 10: Chromium based 337 2756569
>>756564

>Как только


Ну ты понял.
изображение.png28 Кб, 596x187
Linux: Firefox based 338 2756576
>>756559

>притом полный диапазон - 24 КГц


у него нет режима 44100кГц, поэтому он ресемплит до 48кГц.
а срез 20кГц на всех битрейтах (за исключением самых низких) это у него по дефолту.

>Цифровые - идеальны


Смотря какой фильтр. Вот lowpass фильтр у Audacity там срез максимум 48 децибел на октаву. Приходится многократно повторять этот фильтр,что-бы действительно срезать ВЧ.
Неизвестно 339 2756593
>>756576
В Аудишне FFT фильтр начисто срезает, если настроить соответствующе. И отдельный low-pass filter есть вроде бы
Windows 10: Firefox based 340 2762263
Какого хрена опус уже год не обновляется? Всё, кодек допилили до совершенства штоле?
Apple Mac: Safari 341 2762296
>>762263
А почему его должны часто обновлять? Тулсы вообще по несколько лет обновляются, tak вон с 2013 пилится, беты там какие-то. mpc с 2009, wavpack, flac раз в два-три года, это нормально, а народ продолжает массового поедать мертвый mp3, классика.

>>756576
А если у меня исходник PCM в 44, то как быть? SOXом переводить исходник в PCM 48 и жать потом его в opus? или SOXом переводить уже готовый lossy opus 48 в 44, полученный из исходника PCM в 44? Opus вообще сможет в 44 кустарно c вышеописанным и есть ли в этом смысл/плюсы/минусы? Не понимаю в этом. Теряется ли качество из-за PCM 44 пережатый в opus 48, не считая естественной потери pcm->lossy, чисто за частоту дискретизации спрашиваю.
Windows 10: Firefox based 342 2762301
>>762296

> почему его должны часто обновлять


Ну самый свежий из lossy вроде, только в 2012 формат запилили.
Apple Mac: Safari 343 2762338
>>762301
Гуглить то хоть пробовал? Никуда не делся твой opus, развивается.
https://git.xiph.org/?p=opus.git
https://git.xiph.org/?p=opus.git;a=log
Windows 10: Firefox based 344 2762341
>>762338
Тут смотрел: https://opus-codec.org/
Linux: Firefox based 345 2762657
>>762296
Ну в сам opusenc встроен ресемплер. Но если сомневаешься в его качестве, можешь и через sox перегнать.
Передискретизация, с учетом неидевльности lowpass фильтров, может вносить дополнительные искажения. Только вот являются ли они существенными при lossy компрессии?
По умалчанию opusdec такой сигнал снова отресемплит до 44100 Гц. А вот foobar2000 будет воспроизводить в 48 кГц без ресемплинга.
Ещё учти что звуковуха может нативно не поддержитать 44100 Гц. Тогда ей всё равно понадобится ресемплер.
Неизвестно 346 2762790
>>762657

> Ещё учти что звуковуха может нативно не поддержитать 44100 Гц


Все звуковухи реалтек передискретизируют всё аудио в 48 КГц, если в панели 48 стоит, насколько я понимаю.
Windows 7: Firefox based 347 2762961

>2k20


>сжатие

Linux: Firefox based 348 2763027
>>762961
Во-первых лосслес в плане математики ультрапримитивен, там всё изобрели уже 30 лет назад. Чё его в 2к20 обсуждать?
Во-вторых, в 2k20 основной потребитель контента - это мобилки, где размер хранилища определяется маркетингом а не техпроцессами. Да даже компы сейчас стараются укомплектовывать ссд, а данные выносить на насы. Так что сжатие в 2к20 - более чем актуальная тема.
Windows 10: Chromium based 349 2763058
Как вам сжатие в тик токе?
Windows 7: Firefox based 350 2763227
>>763027
Да ты же просто нищук.
Linux: Firefox based 351 2763366
>>763227
Я тебе про ситуацию в экосистеме, а ты мне ad hominem про одного человека. Давай вкатывайся в формальную логику, пока не поздно.
Неизвестно 352 2763417
>>763366
Модус поненс
Windows 7: Firefox based 353 2763468
>>763366
Купи нормальный телефон, а не сяоми, бомж.
Неизвестно 354 2763470
>>763468
На самом деле в 2017 году за 42К айфон имел 32 ГБ (и их не расширить MicroSD), а за 16К Сяоми - 64 ГБ, так что это айфоны обделены хранилищем
Linux: Firefox based 355 2763586
>>763468
Ни в один флагман не удастся всунуть десяток терайбат, как в старую добрую пеку. Потому с раземером в любом случае приходится считаться.
Linux: Chromium based 356 2763879
Да как сука ебаные превью аудио+картинка делать
бурят приди порядок неведи!
Windows 10: Firefox based 357 2763951
bj1.png979 Кб, 1000x1000
Windows 10: Chromium based 358 2766418
>>762657
Вижу ты хорошо шаришь. Не мог бы пояснить еще пару моментов с PCM? С такими вопросами ньюфажин аудиофилы сразу гонят тряпками.

1) Достаточно ли ужимать 24-битные PCM в 16-битный PCM с обычным дизерингом фубара или нужны обязательно всякие нойзшепинги дополнительно для такого?

2) При конвертировании PCM Aiff в PCM Wav идентичной битности теряется ли качество? И тоже нужны ли в таких случаях конвертирования всякие дизеринги и тд/тп?
Неизвестно 359 2766464
>>766418
Я неон, но по 1) скажу, что твоя пекарня издает такой шум, что динамического диапазона 96 дБ даже с дитхерингом без нойз шейпинга выше крыши будет, ты весь этот диапазон не услышишь в условиях существенного фонового шума.
Неизвестно 360 2766466
>>766464
Только непонятно, зачем ужимать, у тебя звуковуха только вывод 16 бит что ли поддерживает? 24 нет?
Неизвестно 361 2766467
>>766464
Точнее, благодаря дитхерингу динамический диапазон даже больше, это уровень шума на -96 дБ
1519647672424.jpg257 Кб, 1200x900
Windows 10: Firefox based 362 2766565
>>686610 (OP)
Но WebP на четвертой объективно хуже. У него же даже морщины разгладились, неужели ты этого не видишь? Типичная ошибка новичка в шакалинге - мыло вместо частичного сохранения деталей.
Windows 10: Chromium based 363 2766567
>>766466
Да просто экономия места, музыки пиздец уже, в облако кидаю не часто прослушиваемые жанры. У меня интернет еще не особо то быстрый, выкачивать потом эти 24, я смысла в них особого не вижу, мне мастерингом не заниматься, бутлегов писать не планирую. А если нужно побаловаться, то всегда можно достать их из первоисточника, в данном случае Bandcamp.
https://bandcamp.com/fossf1/following/genres
https://bandcamp.com/fossf1/following/artists_and_labels
Ты просто глянь на списочек жанров, устанешь, а я всё это чекаю, покупаю, качаю, слежу.

Поясни за второй вопрос, вброшу что-нибудь
132523348627.jpg109 Кб, 540x650
Windows 10: Firefox based 364 2766570
>>686673

>пиздящий данные пользователей через метадату


Наркоман? Током ёбнуть?
Неизвестно 365 2766593
>>766567
А по второму вопросу - я забыл, что за aiff, в чем его особенности. Ну если идентичной битности, то какие могут быть потери? Наверное никаких
Неизвестно 366 2766595
>>766593
И дитхеринг наверное нинужен
Linux: Firefox based 367 2766638
>>766565

>частичного сохранения деталей


Это не частичное сохраненение деталей. Это имитация деталей артефактами сжатия.
Не скажу, что это плохо, кстати.
ffX44uxFoPsz2.png2,3 Мб, 905x905
Windows 10: Chromium based 368 2766649
>>766593
Да это тот же PCM, только эппловский. Блин, раздражает немного что не все кодировщики его поддерживают и в таком случае сначала aif/aiff в wav жать приходится.

Так уж и быть, раздаю бесплатные подарки. Спасибо за инфу. https://www60.zippyshare.com/v/IHyIka4F/file.html
Неизвестно 369 2766652
>>766649

> Да это тот же PCM, только эппловский


ALAC жи есть, я как раз его юзаю, чтобы на афоню скинуть лосслесс музон в Apple Music. Эпловский аналог FLAC. Конвертирую в него из FLAC.
image.jpeg701 Кб, 2208x1242
Неизвестно 370 2766655
>>766649
Спасибо)) играет
Windows 10: Chromium based 371 2766675
>>766652
Да я в данном случае предпочитаю Wavpack, в нем есть неоспоримая фича когда нужна экономия места. Гибридный режим позволяет держать сразу lossless и lossy размером как любой другой lossless контейнер. То бишь возьмем твой трек ALAC, предположим размером 25мб и Wavpack тем же 25мб, в которые ужались сразу lossy и lossless и их общий размер составляет тот же 25мб. А в случае ALAC получится что к этим 25мб нужно еще прибавить ~10 для хранения lossy AAC, получится уже ~35. Я знаю что на FLAC тоже есть такое, но сторонними васянами написано и не уверен будет ли работать везде, уже жаловался народ на траблы. А в Wavpack это из коробки.

>>766655
Что-то с кодировкой не то, перекодируй документ, если нужно, да там ничего важного не написано, просто комментарии для упрощения. Но хоть официально бесплатное и в любом формате.
Windows 7: Firefox based 372 2767650
Как научиться пользоваться архиваторами?

вот например есть файлы, которые когда-нибудь (возможно) понадобятся, но большую часть времени они только валяются на диске. Как их лучше всего упаковывать и сжимать?
Попробовал случайным образом потыкать пресеты 7-Zip, но ничего путного не получилось, а в некоторых случаях архив даже начал больше весить, чем исходные файлы.
Каким образом добиваются уменьшение размера в два раза и выше? Например как в репаках игр или здесь: https://rutracker.org/forum/viewtopic.php?t=5489805
Неизвестно 373 2767663
>>767650
Создаешь профиль по умолчанию в винрар с форматом архива Rar с максимальным сжатием, и если по одному не будешь файлы вытаскивать, то непрерывный архив
sage Android: Mobile Safari 374 2767728
>>686610 (OP)
Православная это шебм4ретардс, ебаный пикабушник.
Linux: Firefox based 375 2769988
>>767728

>FFmpeg


>пикабушник


>Православная это GUI для FFmpeg


совсем дебич? Пошел обратно на свой пикабу и больше не возращайся.
8532-1.jpg136 Кб, 1430x715
Windows 10: Firefox based 376 2777882
Есть 17гб фото в пнг. Чем можно существенно сжать без потери (или с минимальной потерей) в качестве?
Android: Mobile Safari 377 2777883
Каво
Android: Mobile Safari 378 2777887
>>777882
жми в png-zip
Android: Mobile Safari 379 2777914
>>687799
Взгляни на небо, посмотри, там плывут облака
Windows 7: Firefox based 380 2777961
>>777882
cwebp -z 9 -mt image.png -o image.webp
Windows 10: Firefox based 381 2777999
>>777882
cwebp -z 9 -lossless -mt (без потерь)
cwebp -m 6 -z 9 -near_lossless 80 -mt (без визуальных потерь, чем меньше число -near_lossless, тем меньше результат, но больше потерь)

Если просто для хранения, то можно и BMF
https://www.compression.ru/ds/bmf_2_01.rar
Сам формат это не какой то стандарт, но это один из лучших сжимальщиков без потерь, сразу он PNG не понимает, надо предварительно сконвертировать например в PPM:
ffmpeg -i image.png image.ppm

Уже потом сжимать:
BMF.exe -s -O"image.bmf" "image.ppm"
изображение.png19 Кб, 846x272
Windows 10: Firefox based 382 2778105
>>777882
>>777961
>>777999
>>777887
Потестил.
Везде максимальное сжатие без потерь, кроме heic. В нем есть минимальные отклонения. Был бы вином, если бы не зеленил картинку, и нет нормальных приложений для просмотра.
JPC - LuraWave JPEG-2000 Format, без потерь и быстро, но мертвый.
AVIF - oche dolgo, даже в webp будет все конвертироваться ~30 часов.
Windows 10: Chromium based 383 2778178
>>778105
Тут только нужно смотреть как конвертируется в AVIF и HEIC, скорее всего в yuv444/yuv422 (а это уже потери, как при цветовом преобразовании, так и сохраняется меньше самих цветов).
В AVIF настоящий lossless режим есть через https://github.com/AOMediaCodec/libavif
Avifenc --lossless
Для HEIC были какие то форки с RGB, но надо разбираться и размеры там будут существенно выше.
У Webp если недостаточно скорости, можно использовать настройки побыстрее, даже на них результаты вполне себе.
Windows 10: Chromium based 384 2778187
>>778105
Можно еще посмотреть тесты, которые я кидал в другом треде https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/

Также там есть тест PNG оптимизаторов (в табе PNG), в Jpeg XL сжимать на максимальных настройках тоже будет очень медленно, да и сам формат пока еще развивается, вроде как уже стандартизировали, но есть вероятность что новые версии не распакуют старые пикчи, тут уж на свой риск.
Windows 7: Firefox based 385 2778294
>>778178

>В AVIF настоящий lossless режим


Он всё равно в yuv444 перегоняет.
Windows 10: Chromium based 386 2778438
>>778294
Он также в них сохраняет дополнительные данные для обратного преобразования без потерь в RGB, можно почитать объяснение автора на реддите:
https://www.reddit.com/r/AV1/comments/gdi12d/libavif_v073_tagged_including_native_lossless_mode/fplg9s0/
sage Ubuntu Linux: Chromium based 387 2778480
>>686989
шебм хуйня, не перематывается
Windows 7: Firefox based 388 2778567
Как максимально жать в лосслесс авиф? Пробовал "avifenc -l -s 0 image.png image.avif" с этой пикчей >>687799, но результат весит больше, чем лосслесс вебп.
Windows 10: Firefox based 389 2778583
>>778567
xnconvert
Windows 10: Chromium based 390 2778598
>>778480
Что у тебя за калькулятор?
Windows 10: Chromium based 391 2778621
>>778567
Так и жать, если нужен настоящий Lossless, все остальные утилиты жмут в yuv444 не сохраняя дополнительные данные с RGB (можно точно также как они сжимать и avifenc, указав нулевой квантайзер --min 0, но не добавляя lossless). AVIF вообще не особо предназначен для конвертации чего то с RGB в lossless, т.к. у него все это сделано через костыли и очень сильно страдает сжатие.

Некоторые цитаты:

>I don't have any numbers to know whether this is normal or not, but AV1 is designed for lossy encoding, so it is possible. In order to have true lossless RGB, GBR planes are handed to the AV1 encoder, which probably causes the encoder to be less efficient than it could be.


(jdrago)

>YUV444 is not actually lossless. Conversion of 8-bit RGB to 8-bit YCbCr reduces the number of colors from ~16m to ~4m. You're basically not encoding the least significant bits in the red and blue channels - and those are typically high-entropy bits, so you get a close to 2bpp advantage by not encoding them.


(jonsneyers)
Windows 10: Firefox based 392 2778622
>>763470
Кек, а в ноклу 808 из доисторического 2012 можно хоть 2 терабайта карточку засунуть как родную, которых до сих пор не выпустили.
только скорость будет 10 мегов/с
Windows 10: Firefox based 393 2778632
Как одной строчкой команд, а не кучей заходов в ffmpeg нарезать шебмку из огромного fullhd 60fps стрима h264/aac adts, получив на выходе например 640х360 vp9 512kbit / opus 64kbit моно с нормализацией под -1 дБ и срезом частот ниже 20 Гц? Скажем слепить 20 кусочков где-то в районе 04:23:40 - 04:24:02 и 07:45:21 - 07:48:54, в идеале ещё и вырезать из фуллхд оригинала кусок 640х360 в нижнем правом углу и засунуть его в финальный шебм. И всё это сразу одной строкой в консолечке. Чот получится наверно пердолинг не хуже установки генту.
Windows 7: Firefox based 394 2778669
>>778621

>дополнительные данные с RGB


Понятно, откуда лишний вес.
Windows 10: Chromium based 395 2778865
нихуя не понимаю, нахуя рекомендовать heic / avif?
Была папка 7гб, и bmp, и jpg, и png, разные размеры, разное качество, с прозрачностями и без, анимации и без.
Прогнал за 5+ минут с помощью xnview в webp, в результате и проводник читает формат, и папочка сжалась до 1.4гб, и в программах фоточки видны.

Попробовал перегнать сначала те же 7гб в avif / heic (результаты одинаковы), 4% (я хз сколько это мб, может мб 300-350), около часа.
Впизду я ебал такой пиздец. Вы ебанутые.

Ради теста взял AVIF / HEIC / WEBP посмотрел на то, что получилось, и время затраченное.

всё кроме webp не выдерживает никакой блядь критики.
Как по поддержке банально софтом, так и по времени обработки, конвертации, сжатия, и так далее.

Вопрос - нахуя он нужен?
Windows 10: Firefox based 396 2778912
Какой видеокодек жмёт круче всех, чтоб весило хуйню, а качество было неотличимо от оригинала?
Windows 10: Firefox based 397 2778913
>>778865

> времени обработки, конвертации, сжатия


Что, даже на 9900к сраные картиночки жмутся часами?
Linux: Chromium based 398 2778945
Прошу прощёния если уже было.
Хватаем первую попавшуюся в папке гифку (пнг и джипег пока не вкостылены) и приклеиваем звук.
Windows 10: Firefox based 399 2778957
Linux: Firefox based 400 2778978
>>778945
Ну бляя, отступы
Linux: Firefox based 401 2778985
>>778978
Отступы там - самый из незначительных грехов. Он нигде не определяет рабочую папку, потому если запустить скрипт типа ~/scripts/myyobaffmpegwrapper/yoba.sh, то они пидорнёт случайный трек и картинку с хомяка.
Очень ранимая аниме.mp4264 Кб, mp4,
854x480, 0:08
Linux: Chromium based 402 2778991
>>778985
Спасибо за замечания
Windows 7: Firefox based 403 2778996
>>778945

>2020


>vp8


>vorbis

Windows 7: Firefox based 404 2779308
>>778945
Лучше сначала просто перегнать гифку в видео, а после объединить с музычкой:
ffmpeg -i audio.mp3 -stream_loop -1 -i video.webm -c:a libopus -b:a 64k -c:v copy -shortest output.webm
Windows 10: Firefox based 405 2779321
>>779308
А эта хрень работает с многопотоком? Похоже она только одно ядро загружает. :с
Windows 7: Firefox based 406 2779346
>>779321
Можешь -threads 16 добавить, но объединение и так быстро происходит.
Windows 7: Firefox based 407 2779353
>>779308
Стоит так же заметить, что при таком способе размер файла будет больше.
.webm1 Мб, webm,
272x300, 1:18
Windows 7: Firefox based 408 2779354
Windows 10: Firefox based 409 2779376
>>779346
А если надо файл гигов так на 24 перекодировать?
Windows 10: Firefox based 410 2779396
>>778996
С vp9 почему-то добавляется тишина в конец.
Android: Mobile Safari 411 2779433
>>686673
Открытый же
Windows 10: Chromium based 412 2779871
>>778913

>9900k



Не, у меня не 9900k конечно же.
Но i5, довольно производительный.
Поэтому я хз, это нихуя не норма.
Windows 8: Chromium based 413 2780059
Записываю окно с ffmpeg -f framerate 60 -i -title "window_name" -c:v h264_nvenc -qp 0 output.mkv. Курсор двигается, но окно заморожено. Если с такими же параметрами записывать весь экран, то все норм. Чяднт?
Android: Mobile Safari 415 2780093
Чем ваши webpы открывать?
Linux: Firefox based 416 2780096
>>780093
браузером
Linux: Firefox based 417 2780102
>>780093
Gwenview
Windows 10: Firefox based 418 2780138
>>780093
HoneyView
gCCW-BCLWXY.jpg3,1 Мб, 2560x1920
Windows 10: Firefox based 419 2780365
>>778865
>>779871

> HEIC


Лол, ты чем жал? Я через ffmpeg + паковщик (gac) минимум по 10% получал, даже с суперужатых пикч с вк. Если ты не в состоянии понять как оно работает, это не значит, что оно не работает.
Не завезли ещё поддержку, гружу сюда.
https://files.catbox.moe/znx8on.heic
Вот у меня мужик с котом есть. 3 метра превратились в 560кб, разницы я не вижу inb4: слепой.
Кодировалось это всё на slow 4 секунды. На placebo 15.
Делюсь скриптом для красноглазых:
https://pastebin.com/9pwb2kNb
А avif говно, тут согласен. Полчаса одну картинку обрабатывает.
Windows 10: Firefox based 420 2780381
>>780365

> gac


gpac*
Windows 8: Chromium based 421 2780419
Котаны, возможен ли в принципе горизонтальный флип (т.е. зеркальное отображение) видео без пережатия? Ну или как и чем это сделать с минимальными потерями?
Linux: Firefox based 422 2780444
>>780419
Метадатой дописать hflip, например?
https://it-handbook.ru/windows/povorot-mp4-video-s-pomoshhyu-ffmpeg.html
Linux: Firefox based 423 2780477
>>780444
А, сорь, только сейчас посмотрел что не то кинул.
Вот тут чувак флипает метадатой и судя по всему мало какие плееры проигрываю его хотелки: https://superuser.com/questions/1393880/edit-mp4-hex-data-to-vertically-or-horizontally-flip-video-in-a-lossless-manner
Windows 10: Firefox based 424 2780488
>>778945
Соус музыки из первой вебм?
Linux: Chromium based 425 2780513
>>780488
crypt of the necrodancer
Windows 10: Chromium based 426 2780792
>>780365

>минимум по 10% получал, даже с суперужатых пикч с вк


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

>Вот у меня мужик с котом есть. 3 метра превратились в 560кб, разницы я не вижу


Разницу видно, в основном сожрало все детали, но это ладно, бывает что нужна просто фотка поменьше без сильных артефактов

Но если такие потери устраивают, вот для примера WebP даже чуть меньшего размера чем этот HEIC https://files.catbox.moe/uukfg3.webp
(с ним тоже скорей всего разницы не будет видно, а учитывая что у HEIC никогда не будет поддержки в популярных браузерах из-за своих жестких патентов, то смысл все в него все переводить)
Windows 10: Firefox based 427 2780855
Жму аудиокниги и подкасты в opus VBR 56 (ниже уже явное говно и если в книге есть музычка, то лают шакалы). Жал лёгкий тихий джаз для прикола в CBR 64 - охуел от того, что на слух сложно отличить от исходника. Более насыщенная и громкая музыка типа митола естественно рассыпается в говно даже на 128. Всю коллекцию музла из mp3 320 и флака перегнал в ogg vorbis 192, остался доволен.
Всё правильно делаю?

Теперь ищу способ уменьшить размер коллекции манги, в основном ЧБ, смесь жпг и пнг. Что посоветуете? Пытался найти баланс в жпг, на 75 шакалы вроде не так ужасны, но выигрыш по качеству маленький.
Linux: Firefox based 428 2780869
>>780855

> начал с опуса, закончил ворбисом


> пережал из лосси mp3 в лосси ворбис


> Всё правильно делаю?


Ну как сказать. Я согласен, что 192 опуса с ютуба находиться на одном уроне с 320 мр3, но пережимать лосси в лосии - такая себе затея. Потери накапливаются.
Твоё право, если ты разницы не слышишь. Главное это своё говно пережатое потом среди других не распространяй.

> Теперь ищу способ уменьшить размер коллекции манги, в основном ЧБ, смесь жпг и пнг.


Начни с webp. Незначительно проигрывает heif, зато быстр и поддерживается уже практически всеми тостерами.
Linux: Firefox based 429 2780875
>>780855
Алсо если реально ЧБ а не оттенки серого, то можно много выиграть путём принудительной индексации и пнг-оптимизации. Но тут смотреть реальные примеры надо.
Fedora Linux: Firefox based 430 2780876
>>780855
Ты на чем это слушаешь? На динамике лэптопа?
Windows 10: Firefox based 431 2780880
>>780869

>пережал из лосси mp3 в лосси ворбис


320 мп3 это очень хорошее качество, которое от лосслеса хуй кто отличит в принципе. Ну может пара миллионов уникумов на всей планете с феноменальным слухом что-то будут подозревать. Пережимал чтобы место освободить (сотни гигов).

>такая себе затея. Потери накапливаются.


В курсе.

>Твоё право, если ты разницы не слышишь.


Либо не слышу, либо отказываюсь верить, что есть какая-то разница. Музыкант+звукач, зарабатываю этим деньги, со слухом всё ок, всё ещё могу слышать 19500Гц, хотя уже бородат.

> Главное это своё говно пережатое потом среди других не распространяй.


Не понял этого. Зачем я буду свою личную коллекцию музла где-то распространять?

>Начни с webp


Попробую.

>heif


XnConvert почему-то ошибку выдаёт, "файл не является изображением". Через что ещё попробовать?

>>780875
Попробую, спасибо.

>>780876
Слишком толсто. Сосите хуй, пожалуйста.
Windows 10: Chromium based 432 2781116
>>780855

>Теперь ищу способ уменьшить размер коллекции манги, в основном ЧБ, смесь жпг и пнг. Что посоветуете?


Если не так срочно нужна поддержка везде, то можно подождать Jpeg XL, у него очень хорошее lossless сжатие (для перегона пикч с PNG, иногда чуть хуже FLIF, но вот только FLIF существенно медленней, на декодирование даже в десятки раз и он заброшен) и плюс к этому можно уменьшить обычные Jpeg на 20-23% совсем без потерь (пример в онлайне https://google.github.io/brunsli/), ну а с потерями и еще больше.

В другие форматы уже такое себе, ну разве что еще в WebP есть вариант PNG пережать без потерь (все остальное или плохо жмет в lossless или очень медленно), а вот Jpegи пусть лежат, они все таки обычно поменьше PNG весят, да и каждый раз дополнительные потери будут (выйдет еще какой то новый формат и опять захочется пережимать, еще больше все зашакаливая, ну или искать все эти исходники)
Windows 10: Firefox based 433 2781371
>>780869

>начал с опуса, закончил ворбисом


Озадачил ты меня этой фразой, решил проверить. Взял исходник в wav, пережал в vorbis 192 и opus 128, чтобы их размеры были примерно одинаковые. Закинул все 3 в давку и начал сравнивать, пуская в противофазу, ну и хули, как и ожидал - vorbis срезает ультра-высокие как обычно, в противофазе слышно исключительно шипящие, а opus вырезает вообще по всему спектру по чуть-чуть и в противофазе с wav слышно разницу вплоть до суб-низов, но высокочастотное шипение и на vorbis и на opus примерно одинаковое. Вот хуй знает, что из этого лучше - чуть больший срез высоких у vorbis с сохранением всего остального или вырезание по всему спектру у opus.
Linux: Firefox based 434 2781429
>>781371
Ну так. Огг - это всего лишь контейнер. А ворбис и опус - совершенно разные кодеки из разных эпох с разными задачами.
Опус, емпнип, добавляет смещение. Сдвигай фазу для минимизации диффа. Плюс апконвертит в 48000, потому лучше на родной частоте и сравнивать.
Ну и чисто моё мнение. Лучше когда акустическая модель вырезает инфу везде понемногу, чем тупой Lowpass "режьте всех кто выше 18к, господь разберётся где свои".
Windows 10: Firefox based 435 2781607
>>781429

>с разными задачами


Ну вот поэтому я и пережал всю музыку в vorbis 192, а аудиокниги в opus 56 VBR, потому что opus реально круто себя ведёт на таких низких битрейтах и голос в книгах не превращается в глухое бульканье как с другими кодеками.

>Опус, емпнип, добавляет смещение. Сдвигай фазу для минимизации диффа.


Вот про это не знал. Попробую.

>Лучше когда акустическая модель вырезает инфу везде понемногу, чем тупой Lowpass


Скорее вопрос вкуса, да и для разной музыки разный подход скорее нужен. Наверное если прогнать пару десятков очень разных жанров через спек, то обнаружится, что в половине из них информация выше 16-17КГц вообще отсутствует.
Linux: Firefox based 436 2784132
Запарился, короче, вопросом перешакаливания жипега в хеиф. Нашкалил жипегов от q100 до q4, затем каждый пожал хейфом от 100 до 1 и поссчитал ssim по отношению к несжатому оригналу. Ну вот какие выводы просятся:
1) Хейф расшакалваиет пережатый жипег - подтверждено. Конечно только сильно пережатый с q<60 и на определённых настройках, и не больше чем на пару пунктов, но байки "хейф сделал файл лудше" теперь не такие байки.
2) Практически всегда можно не ссать и переживать до heif q80-60 , качество скорее всего останется неизменным, в худшем случае снизится до жипега уровня q95.
3) Нет нужды запариваться и искать первоисточник. Как бы исходник изначально не был пережат - его искажения предсказуемые: либо не хуже чем напортило в жипеге , либо потом перходят в кривую пережатя оригинала.
Пока только глаз, сейчас ещё фотки с другой энтропией попробую.
Linux: Firefox based 437 2784141
Ленка
Linux: Firefox based 438 2784145
Аниме, потому что многим тут важно знать
1589576686552.jpeg13 Кб, 600x800
Android: Mobile Safari 439 2784184
>>784145
чем жмёшь в heif?
Fedora Linux: Firefox based 440 2784282
>>784184
Шакалы, шакалы евривер.
1589611645434.jpeg4 Кб, 523x439
Android: Mobile Safari 441 2784313
>>784282
где?
Windows 7: Firefox based 442 2784548
>>780365

>А avif говно, тут согласен. Полчаса одну картинку обрабатывает.


Так нехуй выкручивать speed на ноль. Оставляй дефолтное значение, можно ещё jobs выставить по количеству потоков проца.
изображение.png545 Кб, 599x594
Linux: Firefox based 443 2796812
Существуют ли енкодеры в опус с ГПУ ускорением?
Windows 7: Firefox based 444 2802370
Обнаружил что у меня была старая версия опуса в гуй-мокропиське. Скачал последнюю, воткнул, заебись. Аудиокниги в 28 VBR охуительно кодируются. Если ниже, то Ш и С начинают люто шуметь, при этом на ультра-высоких добавляется какой-то рваный шум, будто биткрашер навесили.
Windows 10: Chromium based 445 2802464
>>796812
нет и не могут существовать
Linux: Firefox based 446 2802916
>>802464

>не могут существовать


Интересно обоснование этого тезиса.
Windows 10: Chromium based 447 2803544
Почему макак не запилит автоматическое пожатие картинок в ЖИПЕГ? С возможностью покрутить качество или вообще не пожимать, примерно как в дашчане. Заебали картинки в 15 метров.
Windows 10: Firefox based 448 2803570
>>803544
Проблемы замкадска москвича не ебут
fxAoYVUqVQ.png143 Кб, 1204x771
Windows 10: Chromium based 449 2803579
>>802916

> Интересно обоснование этого тезиса.



Может быть бы ты загуглил?
https://minds.wisconsin.edu/bitstream/handle/1793/45041/ECE 790 Hsin-Yu Chen project Report.pdf?sequence=1&isAllowed=y

Но есть некоторые: НО.
То, что он описывает по поводу памяти и синхронизации между КПУ и ГПУ - я не могу сказать что и не актуально, и что актуально.
Т.е. изменения с момента публикации исследования в GPU были, да и производительность увеличилась раз так в 500+ плюс память так же быстрее стала, не говоря о чипах и так далее...

Но и процы тоже быстрее стали на самом деле, не в 500+ раз, но в раз 5+ точно...
sage Windows 7: Firefox based 450 2803627
>>756561
это петушиное кукрекание про прогресс
Windows 10: Chromium based 451 2803662
>>756561

>Популярность и распространённость — вот что действительно важно



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

это касается вообще всего о чем ты слышал:
nginx
winrar
kaspersky
norton
windows
debian
ubuntu
да любой популярный (очень популярный) софт возьми...

Тот же AIMP...
Я очень хорошо помню как он появился...
Он появился когда уже WinAMP всех заебал.
Аимп выглядел свежо, дохуя фич было, реально мощная альтернатива была всяким jetPlayer, Light Alloy, и так далее...
Тем более WinAMP... В ту же пору появился и deadbeaf кстати...
Windows 10: Firefox based 452 2804104
>>756561
Даунич? Опус в ютубе и спотифае.
xIVVOX8ZfC.png21 Кб, 568x659
Windows 10: Chromium based 453 2804172
>>686610 (OP)
решил пожать wmv порнуху, старую, закодированную хуево.
Пытался решить проблему с:
- ffmpeg (чистым, и батниками) - FAILED
- handbrake -> FAILED
- xilsoft -> failed
- movavi converter -> failed
- wondershare uni converter -> failed
- ffmpeg batch converter -> failed
- Any Video Converter -> failed
- Media converter -> failed

Что значит failed?
Нужн понимать что под этим слово кроется неудача в одном из способов решения проблемы:
1.) нужно закодировать одновременно все файлы, а не выбирать по одному.
2.) нужно использовать haccels т.е. hardware acceleration, и дохуя (или почти все) - фейлили с этим.
3.) нужно без мозгоебли и пердоленья закодировать всё, что бы просто было и понятно всё, что есть куда кодировать, и что получим в результате. Тупо почти все слились в этом плане
4.) нужен автоматический подбор оптимальных параметров по видео, что бы кодирование происходило эффективно оставляя похожее качество но с меньшим размером.
5.) само собой не сжатый саунд нужно кодировать в эффективные aac / opus, с этой задачей овердохуя тоже не справилось.
6.) нужно что бы задействовалась видюха полноценно, а не на 3-5%, как в handbrake
7.) идеально что бы и встройка напрягалась
8.) нужно сохранять либо рядом либо в другой папке все сброшенные видосы.

И вот мы подобрались к тому, что только одна софтина справилась с этим всем -> FormatFactory.

Поэтому да - я рекламирую её, как годноту которая просто работает из коробки и делает всё что лично мне было необходимо для 100гб архива прона выкаченного с порнолаба.

Результаты - несколько часов ебли.
Около часа конввертация
В результате получил на 64% меньше размер (36гб, против 102 изначально), при том же качестве визуально видео и аудио.
xIVVOX8ZfC.png21 Кб, 568x659
Windows 10: Chromium based 453 2804172
>>686610 (OP)
решил пожать wmv порнуху, старую, закодированную хуево.
Пытался решить проблему с:
- ffmpeg (чистым, и батниками) - FAILED
- handbrake -> FAILED
- xilsoft -> failed
- movavi converter -> failed
- wondershare uni converter -> failed
- ffmpeg batch converter -> failed
- Any Video Converter -> failed
- Media converter -> failed

Что значит failed?
Нужн понимать что под этим слово кроется неудача в одном из способов решения проблемы:
1.) нужно закодировать одновременно все файлы, а не выбирать по одному.
2.) нужно использовать haccels т.е. hardware acceleration, и дохуя (или почти все) - фейлили с этим.
3.) нужно без мозгоебли и пердоленья закодировать всё, что бы просто было и понятно всё, что есть куда кодировать, и что получим в результате. Тупо почти все слились в этом плане
4.) нужен автоматический подбор оптимальных параметров по видео, что бы кодирование происходило эффективно оставляя похожее качество но с меньшим размером.
5.) само собой не сжатый саунд нужно кодировать в эффективные aac / opus, с этой задачей овердохуя тоже не справилось.
6.) нужно что бы задействовалась видюха полноценно, а не на 3-5%, как в handbrake
7.) идеально что бы и встройка напрягалась
8.) нужно сохранять либо рядом либо в другой папке все сброшенные видосы.

И вот мы подобрались к тому, что только одна софтина справилась с этим всем -> FormatFactory.

Поэтому да - я рекламирую её, как годноту которая просто работает из коробки и делает всё что лично мне было необходимо для 100гб архива прона выкаченного с порнолаба.

Результаты - несколько часов ебли.
Около часа конввертация
В результате получил на 64% меньше размер (36гб, против 102 изначально), при том же качестве визуально видео и аудио.
Linux: Firefox based 454 2804184
Аноны, есть ли в ffmpeg возможность сделать максимально компактный видеоролик по схеме?
1. Вступление ролик1
2. Цикл ролик2
3. Окончание ролик3

Видел, что зацикливали анимации без увеличения объема, а такое можно?
Linux: Firefox based 455 2804186
>>803662
Хуею в винрарщиков, при наличии охуенного и открытого 7z
Windows 7: Firefox based 456 2804258
>>804186
У него гуй и интеграция в систему говно.
Linux: Firefox based 457 2804263
>>804258
Причем тут это?
Вот же делали зацикленный клип без потери прстанства >>778945

Можно ли сделать то же самое, но с вступительным блоком и завершающим?
Windows 7: Firefox based 458 2804476
>>804263

>Причем тут это?


При том, что ответ был на другой пост.
Windows 7: Firefox based 459 2804477
>>804184

>Видел, что зацикливали анимации без увеличения объема


Где?
.png241 Кб, 469x249
Windows 10: Chromium based 460 2804486
>>688040
фапБ ебучее мыло
Linux: Firefox based 461 2804516
>>804477
Ну вот же >>778945
Windows 7: Firefox based 462 2804538
>>804516
Там не зацикливание, а один монолитный видеопоток.
Linux: Firefox based 463 2804632
>>804538
Понятно. Только этот поток не занимает пространство, т.к. один фрагмент повторяется на протяжении всего ролика. Я на 100% уверен, что кодек позволяет нелинейно ссылаться на кадры и можно собрать ролик из циклических фрагментов, которые будут занимать только свой кусок пространства, а не копироваться на весь клип.
Только как это сделать я не знаю, вот и спросил.
Windows 10: Firefox based 464 2805017
>>804186

>при наличии охуенного и открытого 7z


Который настолько охуенен, что целиком распидорашивается от малейшей битовой ошибки.
Linux: Firefox based 465 2805300
>>805017

> малейшей битовой ошибки.


Так-то да, 7z не умеет, но для подавляющего количества задач это не требуется.
А ты сам где это реально применяешь?
Linux: Firefox based 466 2805330
>>805300
Из-за этой хуйни перестал бэкапы жать в 7z. Потому что бэкапы на каком только говне не хранятся.
Windows 7: Palemoon 467 2805335
>>780060
Когда уже вымрут все использующие i и j в циклах вместо осмысленных имён.
>>805017

> целиком распидорашивается от малейшей битовой ошибки


Про такой параметр как размер блока в курсе? Или ты там опять базу данных в единственном экземпляре в режиме непрерывного сжатия жал?
Windows 7: Firefox based 468 2808584
Погонял avif на манге, заебись жмёт. Правда времени дохуя уходит и оперативку забивает моментально, но это не главное. Проблема остаётся в невозможности правильного определения степени сжатия для разного содержания.
По шкале квантизации от 0 до 63:
Цветные картинки жмёт заебись в пределах 10-20 с сохранением отличного качества при размере в 2-4 раза ниже чем жипег.
Если жать чб/серую мангу с этими настройками, жмёт так же в 2-4 раза.
Но если на чб/серых поставить 50-55, жмёт просто охуительно, почти в 10 раз, при этом визуально почти ничего не меняется.
Но если на 50-55 жать цветные, то шакалы просто пиздец.
И как мне, блять, сделать так, что бы из 250гб манги пожать отдельно цветные на одних настройках и чб отдельно на других настройках, при этом не вытаскивая пикчи руками из соответствующих папок, чтобы всё оставалось на своих местах?
Windows 7: Firefox based 469 2808864
>>808584

>Проблема остаётся в невозможности правильного определения степени сжатия для разного содержания.


Надо ещё и размер пикчи учитывать.
Снимок экрана от 2020-06-22 12-04-21.png52 Кб, 871x258
Linux: Firefox based 470 2809352
>>808584
Нашкрептах за пять менут. Имаджмагик может посчитать тебе гистограмму, если на ней буду цвета отличные от серого то картинка цветная. Ну и разрешение так же.
15924970761680.jpg143 Кб, 664x794
Android: Mobile Safari 471 2811635
Господа шакалы, посоветуйте, в какой lossy кодек лучше жать музыку - aac-lc или opus? А может что-то другое? Нужна хорошая поддержка тегов в Windows 10 и Android 7.0+ и поддержка софтом и хардом. Кроме того, интересно, насколько сильно накапливаются искажения при пережатии из mp3 320k?
Windows 7: Firefox based 472 2811952
>>811635
Из mp3 320 можешь жать во что угодно без задней мысли.
По остальным:

aac - на самом деле не так хорош, как принято считать. На низких битрейтах превращается в говно.

opus - можно жать лёгкое музло в 96 vbr, если места жалко. В 128 vbr или даже выше жми любое музло со спокойной душой, разницу с флаком услышат три с половиной аудиофила на оборудовании за квадриллион баксов.

vorbis - на 160-192 vbr отлично жмёт и сохраняет спектр (ниже 160 - обрезка высоких начинается), вариативность битрейта на vbr высокая, где надо - добавлет сколько нужно, где не надо - экономит.

Разница между opus и vorbis - первый вырезает понемногу из всего спектра с упором на высокие, второй режет начиная с ультра высоких, не трогая всё остальное. Сам решай, что тебе важнее. Хотя на указанных выше битрейтах разницы реально никакой. Поддержку тэгов сам проверь. Поставь сам знаешь откуда конвертер xrecode II, жми и смотри. Только для опуса кодек обнови, с https://opus-codec.org/downloads/ -> opus-tools 0.2 (Opus 1.3) -> оттуда файл opusenc.exe достань и засунь туда, где такой же лежит внутри папки xrecode II, замени. Или купи прогу за 15 баксов, там уже третья версия вышла.
Windows 7: Firefox based 473 2811953
>>811635

>поддержка тегов в Windows 10 и Android 7.0+ и поддержка софтом и хардом


foobar2000
Android: Mobile Safari 474 2812085
>>811952
Потестировал, шиндовс 10 из коробки до сих пор не умеет в теги vorbis (хотя полная поддержка opus добавлена год назад), на андроиде с этим тоже есть некоторые проблемы (везде решается установкой стороннего плеера). Наверное, всё же буду жать в AAC, с ним нигде нет проблем, а на качество на низком битрейте мне всё равно, т. к. музыку жму в 256k vbr (мне не нужно максимальное сжатие, просто что-то лучше древнего mp3 и его чехарды с тегами).
15918891299360.jpg35 Кб, 498x445
Android: Mobile Safari 475 2814848
Не тонем
Android: Firefox based 476 2817218
>>812085

>mp3 320k -> aac 256k


А смысл? Если уж пережимать так хотя-бы в 160k, если не меньше.
Windows 10: Chromium based 477 2817281
>>817218
нет смысла никакого.

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

Тоже касается и фото.
Хранить что-то в современных форматах можно лишь для АРХИВАЦИИ, но не как файлы, которыми изредка, да пользуешься, тем более если пользуешься регулярно. Ебли дохуища.
Apple Mac: Firefox based 478 2817644
>>817281

>лишь для АРХИВАЦИИ


>кроме плеера эти форматы и нахуй не нужны


у плееров память не резиновая, ты как бы сам должен это знать, раз юзаеш. У телефонов и смартфонов как бы тоже. но те хотя-бы aac поддерживают (кроме артефактов древности), а смартфоны на android ещё и в opus могут.
Windows 10: Chromium based 479 2817752
>>817218
Для этого исходник нужен, а не этой чушью заниматься, из одного lossy в другой. Даже неизвестно какими способами всё это доставалось, в каком виде это было, с каким софтом, на каких сэмплах писано. Сервисы не особо то брезгуют и за исходник считают и lossy, которые потом же пережимают, набив еще больше искажений. это же касается и людей, кто рипует. Впрочем, что тут говорить, ты и сам это предлагаешь, а потом такие же это выкладывают, с друг другом делятся. Получается нескончаемый круговорот с последующим даунгрейдом. Представь что у тебя одна из этих вариаций, теперь ты предлагаешь из "этого" снова что-то ужимать. Самое банальное и частое: 320 лейбл -> 256aac айтюнс -> V0/V2 бесплатное, а теперь это у тебя и ты со своим

>если уж пережимать так хотя-бы в 160k, если не меньше


лол. разочарую вас, наверное, но такой клоунады lossy релизов в интернетах/сервисах - везде и всюду.
>>817281
Я не вижу в этом сложностей, популярные плееры поддерживают это из коробки, как пекарен, так и мобильные. Да и музыка и так и сяк только в плеерах используется, где еще то и зачем.
>>811952
У тебя устаревшая, последняя это 1.3.1. Да и смысл шареварь ставить, когда достаточно конвертера в фубаре, добавив его же пересобранные энкодеры/декодеры, которые тоже станут работать как на некропекарнях, так и на новых, в этом и вся их разница над официальными.
На худой конец можно и мокрую письку поставить http://www.foveon.de/sonstiges/opusdrop/ , которая еще и сэкономит время, просто закинул в окно и готово.

По сабжу - кому важен lossless на максимальном сжатии, рекомендую tak. гуй уже из коробки, жмет сильнее всех остальных и вдобавок быстрее. Имеет вариативные режимы , от потоков до оптимизаций под процессоры, как некропекарен, так и новых, чтоб еще быстрее было. Кому хочется потестить - скачайте этот релиз в wav https://truthradio.bandcamp.com/album/- жмите во flac с максимальным -8 --keep-foreign-metadata. а так же в tak с максимальным p4m. Разница в общем размере релиза будет в 182 и 160. Если кто-то держит такое в облаке для исходников, то ради экономии может и сгодится. Да и не имеет проблем с этой потерей байтов, которые большинство не учитывают, не используя --keep-foreign-metadata во flac. в результате чего размер от исходного потом отличается, то бишь уже не точная распаковка. Это самый дерьмовый минус у flac. В tak такого нет.

Еще как вариант, можно использовать гибридный режим у WavPack, который в общий размер ужмет lossy и lossless версии. Тоже очень экономная штука, ибо не надо добавлять лишние мегайбайты для случаев хранения релиза в lossy + lossless версий. Суть в чем? flac/lossless 21мб + mp3/opus 7мб = 28 в облаке. или же гибридный wavpack 21мб, в котором уже хранятся обе версии со своим собственным форматом. И это только один трек был, а теперь посчитаем все десять. Неплохая фича для неосиляторов, кто не видит/не слышит разницы в форматах, но ужимать/экономить место хочет (но это только при условии что исходник ему тоже важен для хранения. впрочем, можно и просто для lossy wavpack использовать, так как еще и битность не теряет, да и по тестам интересен. просто малоизвестный формат, который не только в lossless умеет).
Windows 10: Chromium based 479 2817752
>>817218
Для этого исходник нужен, а не этой чушью заниматься, из одного lossy в другой. Даже неизвестно какими способами всё это доставалось, в каком виде это было, с каким софтом, на каких сэмплах писано. Сервисы не особо то брезгуют и за исходник считают и lossy, которые потом же пережимают, набив еще больше искажений. это же касается и людей, кто рипует. Впрочем, что тут говорить, ты и сам это предлагаешь, а потом такие же это выкладывают, с друг другом делятся. Получается нескончаемый круговорот с последующим даунгрейдом. Представь что у тебя одна из этих вариаций, теперь ты предлагаешь из "этого" снова что-то ужимать. Самое банальное и частое: 320 лейбл -> 256aac айтюнс -> V0/V2 бесплатное, а теперь это у тебя и ты со своим

>если уж пережимать так хотя-бы в 160k, если не меньше


лол. разочарую вас, наверное, но такой клоунады lossy релизов в интернетах/сервисах - везде и всюду.
>>817281
Я не вижу в этом сложностей, популярные плееры поддерживают это из коробки, как пекарен, так и мобильные. Да и музыка и так и сяк только в плеерах используется, где еще то и зачем.
>>811952
У тебя устаревшая, последняя это 1.3.1. Да и смысл шареварь ставить, когда достаточно конвертера в фубаре, добавив его же пересобранные энкодеры/декодеры, которые тоже станут работать как на некропекарнях, так и на новых, в этом и вся их разница над официальными.
На худой конец можно и мокрую письку поставить http://www.foveon.de/sonstiges/opusdrop/ , которая еще и сэкономит время, просто закинул в окно и готово.

По сабжу - кому важен lossless на максимальном сжатии, рекомендую tak. гуй уже из коробки, жмет сильнее всех остальных и вдобавок быстрее. Имеет вариативные режимы , от потоков до оптимизаций под процессоры, как некропекарен, так и новых, чтоб еще быстрее было. Кому хочется потестить - скачайте этот релиз в wav https://truthradio.bandcamp.com/album/- жмите во flac с максимальным -8 --keep-foreign-metadata. а так же в tak с максимальным p4m. Разница в общем размере релиза будет в 182 и 160. Если кто-то держит такое в облаке для исходников, то ради экономии может и сгодится. Да и не имеет проблем с этой потерей байтов, которые большинство не учитывают, не используя --keep-foreign-metadata во flac. в результате чего размер от исходного потом отличается, то бишь уже не точная распаковка. Это самый дерьмовый минус у flac. В tak такого нет.

Еще как вариант, можно использовать гибридный режим у WavPack, который в общий размер ужмет lossy и lossless версии. Тоже очень экономная штука, ибо не надо добавлять лишние мегайбайты для случаев хранения релиза в lossy + lossless версий. Суть в чем? flac/lossless 21мб + mp3/opus 7мб = 28 в облаке. или же гибридный wavpack 21мб, в котором уже хранятся обе версии со своим собственным форматом. И это только один трек был, а теперь посчитаем все десять. Неплохая фича для неосиляторов, кто не видит/не слышит разницы в форматах, но ужимать/экономить место хочет (но это только при условии что исходник ему тоже важен для хранения. впрочем, можно и просто для lossy wavpack использовать, так как еще и битность не теряет, да и по тестам интересен. просто малоизвестный формат, который не только в lossless умеет).
Windows 10: Chromium based 480 2818559
>>817644
>>817752

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

Потом по работе понадобилось запилить клипчики на ютуб, фш, AF, и так далее - и тут я сел на жопу. Потому что даже современное лицензионное ПО не поддерживает эти всякие ваши форматы. Причем проблема не только в этом, ещё хуже в том, что софт который нужен для работы - часто вообще не поддерживает ничего кроме: jpg, mp4, gif, png, bmp, mp3, wav.
Всё остальное - впизду, нахуй блядь.
Android: Mobile Safari 481 2818582
>>818559

>Потом по работе понадобилось запилить клипчики на ютуб, фш, AF, и так далее - и тут я сел на жопу


Сам ты нипанимаеш. Ты сел на жопу не потому что форматы плохие, и даже не из-за кривого ентерпрайзного софта, а потому что ты lossless исходники удалил без бекапа. Страдай теперь, сам виноват.
Windows 7: Firefox based 482 2818780
>>818559
Имплаинг что кто-то кроме 0.01% потенциальной аудитории на ютубе заметит разницу, если в клип воткнуть 3 раза пережатый звук. Лишние проблемы себе создаёшь на ровном месте.

>не поддерживает эти всякие ваши форматы. Причем проблема не только в этом, ещё хуже в том, что софт который нужен для работы - часто вообще не поддерживает ничего кроме: jpg, mp4, gif, png, bmp, mp3, wav.


Ну так пережми обратно в поддерживаемые форматы и отложи в сторонку, на время работы, а потом удали нахуй. В чём проблема-то? Или аудиофил дохуя?
Windows 10: Firefox based 483 2819252
ОДИННАДЦАТЬ ЧАСОВ
https://youtu.be/B-w03icSDFE?t=328
Windows 10: Firefox based 484 2819466
Ради интереса сравнил MP3 (lame), AAC-LC (qaac), Vorbis (libvorbis) Opus (libopus). Кодировал Rammstein - Ich Will и Gorillaz - Clint Eastwood, 64kbit, все кодеки в режиме VBR. Для Gorillaz - Opus, Vorbis, AAC-LC>говно>MP3. Раммштайн, судя по всему, был сложнее для сжатия, поэтому Opus>Vorbis>моча>AAC-LC>говно>MP3. Надо отметить, что AAC-LC не очень жалует высокие частоты при сложной композиции, а также все кодеки, кроме MP3, работали с частотой дискретизации 44100 и выше.
Windows 10: Chromium based 485 2819469
>>819252
Хуле ебало скорчил? Я слона >>716698 16 часов кодировал.
Windows 10: Firefox based 486 2819490
>>819469
Круто чё, теперь даже африканские дети смогут оценить отечественный кинематограф
Windows 7: Firefox based 487 2819745
>>819466
Ну да, всё правильно. В митоле очень высокая плотность высоких частот из-за гитар с дисторшеном и громких железок. Поэтому все лосси кодеки жиденько обсираются при недостаточном битрейте. Для себя нашёл минимум для митола и всякой сложной электроники - 96 VBR Opus и 160 VBR Vorbis. Ниже - на опусе начинается сужение стерео на высоких частотах (широкие тарелки, например, начинают звучать ближе к центру, теряется пространство), а на ворбисе ниже 160 начинают обрезаться ультра-высокие (можно заморочиться и посмотреть каждый битрей через spek).
Linux: Firefox based 488 2819844
>>819252
Всю жизнь кинчики оставляли сжимать на ночь, тоже мне срок. Когда речь идёт о "сжал один раз" - "скачал миллион раз" то как вполне себе затраты окупаются.
Windows 10: Chromium based 489 2820795
>>819745
А вас не смущает перманентный апсэмпл из 44 в 48 в опусе? Это вообще хорошо для качества? Хочу определиться с форматом, но вызывает вопросы. mp3/aac отпадают.
Windows 7: Firefox based 490 2820805
>>820795

>Это вообще хорошо для качества?


Это похуй для качества. Не забивай голову аудиофильскими бреднями.
мимо-звукач
Apple Mac: Safari 491 2820843
>>820805
Для lossy формата это похуй для качества. Ты от сжатия больше теряешь, чем от передискретизации.
Windows 10: Chromium based 492 2820977
не знаю, как я сюда попал но на всякий случай спрошу
как порезать АПЕ фубаром, если он дает файл целиком, без треков? сторонний софт не хочется ставить
Linux: Firefox based 493 2820980
>>820795
Сама передискретизации в большую сторону - операция без потерь, спасибо за это Котельникову.
Проблема в том что после передискретизации происходит повторное квантование. Но на фоне сжатия - это потери ультрамилипиздрические. Что-то уровня дроча на джиттер-коррекцию. Можешь не забивать голову.
Linux: Firefox based 494 2820983
>>820977
cue файл есть?
Windows 10: Chromium based 495 2821001
>>820977
Cue файл вбрасывай в фубар, увидишь треки, выделяешь их и жмешь конвертацию в нужный тебе формат. Для поносного апе в фубар еще и плагин ставить нужно, да и сам апе лучше на "так" заменить - лучше и не столь требователен, быстрее сделает. А раз плеер не поддерживает, то надо выбирать кастомный режим, прописывать путь до mac.exe и вводить нужные ключи вручную, а их еще надо знать. Сам mac.exe еще и скачать нужно, а официально он только в виде инсталятора есть, что тоже ебанутость. Я не советую этот формат, никаких плюсов, пережми его в любой другой, какой нравится.

А можешь просто CUE Tools поставить, это гораздо проще к освоению и ничего уже не требует.
audiotestrammstein.mp44 Мб, mp4,
640x360, 1:21
Windows 10: Firefox based 496 2821293
Сделал наглядный тест аудиокодеков
Windows 10: Chromium based 497 2821301
>>821001
все ясно!
Удалил и забыл. Пусть сами ебутся со своим обезьяньим говном.
Windows 7: Firefox based 498 2821349
>>821293
aac ожидаемо соснул у opus и vorbis на 64kbps. Хотя для митала ни тот ни другой на таком низком битрейте не подходит, тарелки и гитары теряют ширину резко.
Windows 10: Firefox based 499 2821354
>>821349

>митала


нинужная хуета
Android: Mobile Safari 500 2821359
>>821349
Надо заметить, что здесь используется профиль Low Complexity (LC), который не использует специальные фильтры для низких битрейтов.
Android: Mobile Safari 501 2821485
Android: Mobile Safari 502 2821594
>>821485
Лет через 10, когда будет работать на любой микроволновке, ухх заживём!
Windows 10: Chromium based 503 2821947
>>686610 (OP)
Объясните чайнику, пожалуйста

Что лучше 264 или 265? Важно, впрочем, качество приближенное к оригинальналу.
Windows 10: Chromium based 504 2821949
>>821947
Просто только недавно об этом вообще услышал.
И пиздец статьи и статьи, столько инфы, а нахуй ничего не понятно
Android: Mobile Safari 505 2822112
>>821947
264 быстрее, 265 лучше жмет
Windows 10: Chromium based 506 2822129
>>822112
На качество кадров не влияет, никак?
Linux: Firefox based 507 2822189
>>822129

> 265 лучше жмет


нужно читать как

> при одинаковом размере файлов 264 будет выглядеть хуёвее

Обновить тред