Двач.hk не отвечает.
Вы видите копию треда, сохраненную 15 августа 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 15 августа 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Унижаем 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/
Православная утилита кодирования - FFmpeg:
https://www.ffmpeg.org/
Вики по использованию :
http://trac.ffmpeg.org/wiki
GUI - FFmpeg Batch:
https://sourceforge.net/projects/ffmpeg-batch/
46 Кб, 1080x608Третьего дня по совету проверенного поискового гиганта эксперементирую с новым мегаформатом webp, задыхаясь от жадности к хранилищу, перекодировал пак трапов. Размер и качество, мое почтение, хорошо сделали. Кроме того, удаление шумов и артефактов приятно щекочет простату. Был решительно готов закодировать все фото, однако, малолетнему кодеру невдомек, что метаданные удалять не стои. Как побороть проблему?
>>686616
когда сделают на фчане, абу запилит сюда через неделю-две. с вебмами так же было, хотя вебмы действительно более значимы.
когда сделают на фчане, абу запилит сюда через неделю-две. с вебмами так же было, хотя вебмы действительно более значимы.
>>686662
А не, пизжу, не работает.
А не, пизжу, не работает.
>>686610 (OP)
Очередной зонд пиздящий данные пользователей через метадату. Хотя что еще ожидать от компании специализирующейся на ботнетах.
> WebP
Очередной зонд пиздящий данные пользователей через метадату. Хотя что еще ожидать от компании специализирующейся на ботнетах.
>>686673
У меня как раз обратная проблема: он не сохраняет метадату из жпега
У меня как раз обратная проблема: он не сохраняет метадату из жпега
>>686989
учитывая что для vp9 нет хардварного энкодинга на gpu, HEVC сжимается хардварно на огромном количестве видимокарт, а сжатие vp9 занимает овердохуя времени имею сказать следующее - ебитес врот своим vp9
av1 ваще нахуй нинужон, по тем же причинам
учитывая что для vp9 нет хардварного энкодинга на gpu, HEVC сжимается хардварно на огромном количестве видимокарт, а сжатие vp9 занимает овердохуя времени имею сказать следующее - ебитес врот своим vp9
av1 ваще нахуй нинужон, по тем же причинам
из-за чего получается такой блок серый снизу? я просто перекодировал
45 Кб, 380x604>>686610 (OP)
Новые люди, новое время, когда то по моим алгоритмом работало сжатие, один раз мы пытались сжать ядро планет, что бы получать неограниченное тепло, но математические алгоритмы не сработали!
Новые люди, новое время, когда то по моим алгоритмом работало сжатие, один раз мы пытались сжать ядро планет, что бы получать неограниченное тепло, но математические алгоритмы не сработали!
109 Кб, 288x224>>686610 (OP)
Вся суть вебп одной картинкой. Меньше артефактов - меньше деталей.
Алсо вебп, в отличие от того же heif не умеет в градиенты.
Вся суть вебп одной картинкой. Меньше артефактов - меньше деталей.
Алсо вебп, в отличие от того же heif не умеет в градиенты.
26 Кб, 260x362>>687664
Нет.
Не опенсорс, уноси.
Эм что?
>меньше деталей.
Нет.
> Алсо вебп, в отличие от того же heif
Не опенсорс, уноси.
>не умеет в градиенты.
Эм что?
>>686610 (OP)
Чем avif под пердолексом пожать?
Чем avif под пердолексом пожать?
2,6 Мб, 3240x1742>>687799
Как этот хентай можно сравнивать с божественным вебпом?? Все детали жпега - это артефактная лестница
Как этот хентай можно сравнивать с божественным вебпом?? Все детали жпега - это артефактная лестница
>>688040
png лучше всех, чтоб и требовалось доказать
png лучше всех, чтоб и требовалось доказать
>>688040
Этот хентай поддерживается в любом браузере, в любой перделке. Вебп - гуглоговно без задач.
Этот хентай поддерживается в любом браузере, в любой перделке. Вебп - гуглоговно без задач.
31 Кб, 480x319>>688074
Говно мамонта
Говно мамонта
>>686610 (OP)
А нахуй надо? Глобальное потепление приближать, но зато Абу за хостинг меньше платить?
А нахуй надо? Глобальное потепление приближать, но зато Абу за хостинг меньше платить?
59 Кб, 1080x1920>>688356
Последняя версия?
Последняя версия?
>>688727
Имитировать детали артефактами, например? 30 лет так живём уже.
Можно было бы анализировать картинку и по маске псевдослучайный шум перлина натягивать, чтобы этой кожи младенца не было.
Имитировать детали артефактами, например? 30 лет так живём уже.
Можно было бы анализировать картинку и по маске псевдослучайный шум перлина натягивать, чтобы этой кожи младенца не было.
>>688736
Короче свёл исвудыча, чтобы размеры были одинаковые.
8576 clee.jpg (jpegoptim --size=8k)
8522 clee-26.webp (cwebp -q 26)
8251 clee-28.heif (heif-enc -q 28)
Короче свёл исвудыча, чтобы размеры были одинаковые.
8576 clee.jpg (jpegoptim --size=8k)
8522 clee-26.webp (cwebp -q 26)
8251 clee-28.heif (heif-enc -q 28)
>>688736
Но мыло лучше артефактов, особенно в движении. А шум это уже какая-то отсебятина.
Но мыло лучше артефактов, особенно в движении. А шум это уже какая-то отсебятина.
>>688759
Мыло нужно видемокодекам, чтобы вектора движения долго можно было использовать и не накапливать ошибку.
В статических кодеках рулят другие принципы.
Мыло нужно видемокодекам, чтобы вектора движения долго можно было использовать и не накапливать ошибку.
В статических кодеках рулят другие принципы.
302 Кб, 464x604>>688758
Последний эксперимент: даунскел до 0.5, webp оптимизация до 8282 байт (-q 78) и последующий апскел через ESRGAN.
Последний эксперимент: даунскел до 0.5, webp оптимизация до 8282 байт (-q 78) и последующий апскел через ESRGAN.
>>687799
Эхх, а сейчас там заборов понаставили, нипалазать.
Эхх, а сейчас там заборов понаставили, нипалазать.
Говорят, что ав1 будет лучше хевка. Что-то мне сдается, что это пиздеж. Даже хевк против х264 хуже в плане детализации. Сужу по примерам аниме, неоднократно делал сравнения.
>>688538
>>687876
Короче енкодер avif я нашёл тут: https://github.com/Kagami/go-avif/releases
Где бы теперь декодер найти, чтобы без конпеляции и пердолинга?
>>687876
Короче енкодер avif я нашёл тут: https://github.com/Kagami/go-avif/releases
Где бы теперь декодер найти, чтобы без конпеляции и пердолинга?
Забил короче на avif, оставил jpg, webp и heif. Скрипт берёт картинку и жмёт тремя разными кодеками до одинакового размера.
Тут глаз в 4, 6, 8 и 10 кб.
Тут глаз в 4, 6, 8 и 10 кб.
>>692137
Норм
Норм
>>692145
Здесь heif закодировал больше всего деталей, хотя заметны мазки внутрикадрового предсказания
heif > webp > jpeg
>>692148
Здесь heif сосёт.
Лицо как у куклы, выглядит пластмассово. Гиганские блоки с явными арктефактами звона. Внутрикадровый предиткор превратил брови в прямые линии.
webp > heif > jpeg
Здесь heif закодировал больше всего деталей, хотя заметны мазки внутрикадрового предсказания
heif > webp > jpeg
>>692148
Здесь heif сосёт.
Лицо как у куклы, выглядит пластмассово. Гиганские блоки с явными арктефактами звона. Внутрикадровый предиткор превратил брови в прямые линии.
webp > heif > jpeg
>>694531
*килобайта и кбайт соосветсвенно
*килобайта и кбайт соосветсвенно
>>686610 (OP)
Забыли ссылку на гайд по webm кодированию в шапку треда добавить
https://github.com/pituz/webm-thread/wiki/webm-encoding
Забыли ссылку на гайд по webm кодированию в шапку треда добавить
https://github.com/pituz/webm-thread/wiki/webm-encoding
>>694531
Эта картинка была вручную была собрана из максимально сжатых вариантов, не сравнивай по ней, сравнивай по 3к варианту.
Насчёт этого бы поспорил. Чисто внешне по количеству деталей webp тот же жипег, но у жипега артефакты уже приелись, а webpшное мыло реально глаза мозолит.
>Переделывай.
Эта картинка была вручную была собрана из максимально сжатых вариантов, не сравнивай по ней, сравнивай по 3к варианту.
> webp > jpeg
Насчёт этого бы поспорил. Чисто внешне по количеству деталей webp тот же жипег, но у жипега артефакты уже приелись, а webpшное мыло реально глаза мозолит.
>>695096
то есть тебя не смущает убитая цветопередача вследствии задранного квантователя и примитивного алгоритма компрессии.
Как по мне вместо хранения ВЧ квантованных до металлического звона лучше срезать их НЧ фильтром и сохранить изображение в меньшем разрешении.
WEBP хотя бы пытается замаскировать блочность, как и h264 и всё что после него.
Главная проблема webp в том, что там даже не vp9, а устаревший vp8. Ещё одна проблема этого формата в том, что хоть там и взяли за основу видеокодек vp8, но анимации он сжимает только intra фреймами. Из-за этого гифки сжимаются в лучшем случае на 50%. Поэтому я в 2019м кодирую гифки в неудобный для infinite-loop анимаций формат webm.
Еще сейчас набирает популярность формат apng. Это lossless формат, который сжимает гифки на 5%. Да, у него есть преимущество перед gif, так как он может закодировать true color анимации без потерь, да еще и с настоящим альфа каналом. Но большинство гифок это нарезки из фильмов, зашумленные дизерингом из-за ограничения в 256 цветов на одном фрейме, и там это lossless кодирование не нужно в принципе.
>жипега артефакты уже приелись, а webpшное мыло реально глаза мозолит
то есть тебя не смущает убитая цветопередача вследствии задранного квантователя и примитивного алгоритма компрессии.
Как по мне вместо хранения ВЧ квантованных до металлического звона лучше срезать их НЧ фильтром и сохранить изображение в меньшем разрешении.
WEBP хотя бы пытается замаскировать блочность, как и h264 и всё что после него.
Главная проблема webp в том, что там даже не vp9, а устаревший vp8. Ещё одна проблема этого формата в том, что хоть там и взяли за основу видеокодек vp8, но анимации он сжимает только intra фреймами. Из-за этого гифки сжимаются в лучшем случае на 50%. Поэтому я в 2019м кодирую гифки в неудобный для infinite-loop анимаций формат webm.
Еще сейчас набирает популярность формат apng. Это lossless формат, который сжимает гифки на 5%. Да, у него есть преимущество перед gif, так как он может закодировать true color анимации без потерь, да еще и с настоящим альфа каналом. Но большинство гифок это нарезки из фильмов, зашумленные дизерингом из-за ограничения в 256 цветов на одном фрейме, и там это lossless кодирование не нужно в принципе.
>>695497
Для этой хуйни уже появились оптимизаторы, затирающие повторяющиеся части у последующих кадров?
>apng
Для этой хуйни уже появились оптимизаторы, затирающие повторяющиеся части у последующих кадров?
123 Кб, 471x513>>686610 (OP)
Если не рассматривать картинку увеличенной в близи, то, ЖПЕГ безоговорочно лучше, больше деталей и информации сохранено.
>4 пик
Если не рассматривать картинку увеличенной в близи, то, ЖПЕГ безоговорочно лучше, больше деталей и информации сохранено.
>>696104
Во сколько раз нужно уменьшить картинку, что-бы jpeg стал лучше?
Во сколько раз нужно уменьшить картинку, что-бы jpeg стал лучше?
>>696469
На вдвое уменьшенном прекрасно видна разницу. Ноздря, складка меж глаз, морщина на лбу, текстура кожи, лысина за линзой очков.
На вдвое уменьшенном прекрасно видна разницу. Ноздря, складка меж глаз, морщина на лбу, текстура кожи, лысина за линзой очков.
4 Кб, 438x438>>696918
Я вижу низкочастотные (те которые в левом верхнем углу на пикрелейтед) базисы дискретно косинусного преобразования, а не детали. Их убил задранный донельзя квантователь. А от даунскейла низкие частоты смещаются к более высоким, а высокие пропадают, так как их срезают для предотвращения алиасинга. В данном случае мы не видим потерю высоких при даунскейле, поскольку их и небыло в данном пережатке.
>На вдвое уменьшенном прекрасно видна разницу. Ноздря, складка меж глаз, морщина на лбу, текстура кожи, лысина за линзой очков.
Я вижу низкочастотные (те которые в левом верхнем углу на пикрелейтед) базисы дискретно косинусного преобразования, а не детали. Их убил задранный донельзя квантователь. А от даунскейла низкие частоты смещаются к более высоким, а высокие пропадают, так как их срезают для предотвращения алиасинга. В данном случае мы не видим потерю высоких при даунскейле, поскольку их и небыло в данном пережатке.
>>698047
Никак, изучай плюсы, матан, питон, алгоритмы, нейронки, машоб
Никак, изучай плюсы, матан, питон, алгоритмы, нейронки, машоб
>>698030
Ну вот и говорит о том что с лева.
С лева видно больше деталей.
>Tы слегка перепутал, jpg это то, что слева.
Ну вот и говорит о том что с лева.
С лева видно больше деталей.
>>697986
Ты математику свою вшивую в оценку сжатия не неси. А то уже целое поколение долбоёбов выросло, которые музыкальные кодеки по спектрограмме оценивают.
Единственно корректная оценка методов сжатия - это визуальная оценка большинством живых людей.
Ты математику свою вшивую в оценку сжатия не неси. А то уже целое поколение долбоёбов выросло, которые музыкальные кодеки по спектрограмме оценивают.
Единственно корректная оценка методов сжатия - это визуальная оценка большинством живых людей.
>>698130
Свидетели деталей, что с вами не так?
Если закодировать mp3 в 32 кбит/c, задрав срез lowpass фильтра на 20кГц, используя кодировщик, псиоакустическая модель которого позволяет сделать такое, ты получишь больше частот, ценой увеличения металлического звона и общего снижения качества, так как на те-же частоты выделяется меньше битрейта.
В случае с ОП - пиком, там размер файла настолько мал, что на деталей бит не осталось, всё в квадратики ушло.
Так вы только снижаете разницу между кодеками
Я может быть бы и молчал, если бы jpeg картинка не рассыпалась на эти самые базисы ДКП, и свидетели деталей тоже бы молчали.
Кому то нравится пиксельное говно, кому-то зашакаленное, кому-то мыльное.
Я вижу, то что у webp отображается как линии и контуры, то у jpeg превратилось в кашу из блоков. А ведь линии и контуры это тоже детали.
Свидетели деталей, что с вами не так?
Если закодировать mp3 в 32 кбит/c, задрав срез lowpass фильтра на 20кГц, используя кодировщик, псиоакустическая модель которого позволяет сделать такое, ты получишь больше частот, ценой увеличения металлического звона и общего снижения качества, так как на те-же частоты выделяется меньше битрейта.
В случае с ОП - пиком, там размер файла настолько мал, что на деталей бит не осталось, всё в квадратики ушло.
>А давайте мы снизим разрешение и посмотрим на квадратики еще и интерполяции. В jpeg квадратики больше, значит и деталей больше.
Так вы только снижаете разницу между кодеками
>Ты математику свою вшивую в оценку сжатия не неси.
Я может быть бы и молчал, если бы jpeg картинка не рассыпалась на эти самые базисы ДКП, и свидетели деталей тоже бы молчали.
>Единственно корректная оценка методов сжатия - это визуальная оценка большинством живых людей.
Кому то нравится пиксельное говно, кому-то зашакаленное, кому-то мыльное.
Я вижу, то что у webp отображается как линии и контуры, то у jpeg превратилось в кашу из блоков. А ведь линии и контуры это тоже детали.
7 Кб, 736x460>>2698490
Одобряю, работает
>>698570
Привет подстилка нариманова
Привет подстилка нариманова
18 Кб, 474x301>>698471
Нет ноздри в твоём webp, пропала. Шакал без ноздри не шакал.
Ну давай хоть MSE посчитай чтоле, идиота кусок.
jpeg основан НА МОДЕЛИ ВОСПРИЯТИЯ ЧЕЛОВЕКА, неважно что кому нравиться, он использует объективную метрику, может неидеальную, но основанную на объективных свойствах человеческого восприятия.
Белое пятно лучше квадратных глаз и носа?
Без глаз и носа непонятно что это, человеческое лицо, или тупой фиолетовый двачер.
Нет ноздри в твоём webp, пропала. Шакал без ноздри не шакал.
>Кому то нравится пиксельное говно, кому-то зашакаленное, кому-то мыльное.
Ну давай хоть MSE посчитай чтоле, идиота кусок.
jpeg основан НА МОДЕЛИ ВОСПРИЯТИЯ ЧЕЛОВЕКА, неважно что кому нравиться, он использует объективную метрику, может неидеальную, но основанную на объективных свойствах человеческого восприятия.
>Я вижу, то что у webp отображается как линии и контуры
Белое пятно лучше квадратных глаз и носа?
Без глаз и носа непонятно что это, человеческое лицо, или тупой фиолетовый двачер.
>>698570
Хорошая собачка, держи кость.
Хорошая собачка, держи кость.
>>692149
WebP - замылил дорогу, замылил лес.
Потерял цвета на дороге.
Сделал логотип на строении слева ЧЕРНО-БЕЛЫМ.
WebP - замылил дорогу, замылил лес.
Потерял цвета на дороге.
Сделал логотип на строении слева ЧЕРНО-БЕЛЫМ.
1,1 Мб, 1080x1497>>698608
Что за сука сжимала webp?
Что за сука сжимала webp?
268 Кб, 711x493>>698589
Ты можешь сколько угодно усираться что
но он всё равно не может закодировать линии в 3,6кБ.
Здесь я специально обвел области на которых у webp линии более менее четкие в то время как у jpeg там каша из блоков
Ты можешь сколько угодно усираться что
>jpeg основан НА МОДЕЛИ ВОСПРИЯТИЯ ЧЕЛОВЕКА
но он всё равно не может закодировать линии в 3,6кБ.
Здесь я специально обвел области на которых у webp линии более менее четкие в то время как у jpeg там каша из блоков
>>698128
еще ни разу не открывался
как будто он существует
и так заблокированы
убить можно только то что есть
то-то я в современной порнухе эти тентакли видел, это же инопланетные глисты
>Канал связи с космосом
еще ни разу не открывался
>Закрывает третий глаз
как будто он существует
>блокирует чакры
и так заблокированы
>Убивает бога
убить можно только то что есть
>выводит пришельцев
то-то я в современной порнухе эти тентакли видел, это же инопланетные глисты
>>702958
Только браузеры через avif.js.
Только браузеры через avif.js.
>>703429
спосебо, но это говно какое-то.
спосебо, но это говно какое-то.
Хуй знает как этот ваш heif жать, нашел какой-то онлайн конвертер, но он цвета проебал
>>703440
Перед тем, как выкладывать результаты в пнг, удаляй метаданные о цвете в tweakpng. Или же следи, чтобы они были одинаковые у всех пикч.
Перед тем, как выкладывать результаты в пнг, удаляй метаданные о цвете в tweakpng. Или же следи, чтобы они были одинаковые у всех пикч.
>>703440
avif>webp
Да, там деталей побольше, словно render distance выкрутили. Но облака мыльнее, да.
avif vs heif
Как это вообще сравнивать?
Возникает ощущение, что кодировщик heic вместо тебя редактирует уровни. Вы уж там разберитесь с full->tv->full range преобразованиями.
По детализации разница не большая, но heif кажется детальнее (это при том что avif сложнее кодировать). Может avif потом допилят по качеству. Пока они ускоряют декодеры.
avif>webp
Да, там деталей побольше, словно render distance выкрутили. Но облака мыльнее, да.
avif vs heif
Как это вообще сравнивать?
Возникает ощущение, что кодировщик heic вместо тебя редактирует уровни. Вы уж там разберитесь с full->tv->full range преобразованиями.
По детализации разница не большая, но heif кажется детальнее (это при том что avif сложнее кодировать). Может avif потом допилят по качеству. Пока они ускоряют декодеры.
Помогите объяснить необъяснимую хуйню. Я запостил в клиент вотсапа видео ролик, и если его проиграть - видно последний кадр. НО, если проиграть его в VLC или даже открыть в VirtualDub - этого кадра там нет! Это как блять?
Ролик и два скрина - с ватсапа и VirtualDub - последние кадры. И они не совпадают.
Ролик и два скрина - с ватсапа и VirtualDub - последние кадры. И они не совпадают.
13,9 Мб, webm,1920x1080, 0:16
4,5 Мб, webm,1280x720, 0:13
530 Кб, mp4,1280x720, 0:13
522 Кб, webm,1280x720, 0:13
бамп
>>709158
Зачем так кодировать? Как можно сравнивать x264 закодированный за 6 секунд с av1, который кодировался 6 часов?
Если уж и сравнивать, то на placebo, ну или в крайнем случае на veryslow.
>libx264 slow 320k (6s)
>libx265 slow 320k (55s)
>libvpx-vp9 320k (3m)
>libaom-av1 320k (6h 15m)
Зачем так кодировать? Как можно сравнивать x264 закодированный за 6 секунд с av1, который кодировался 6 часов?
Если уж и сравнивать, то на placebo, ну или в крайнем случае на veryslow.
>>711339
На таком битрейте будет одинаково хуевым.
>Если уж и сравнивать, то на placebo, ну или в крайнем случае на veryslow.
На таком битрейте будет одинаково хуевым.
Sup, подскажите как достать аудио дорожку из видео. А после склеить с видеорядом лучшего качества.
>>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
Достаем звук:
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
>>711633
а какого-то гуи для этого вашего ффмпега не изобрели еще? чтоб не печатать 100 символов а сделать 5 кликов?
а какого-то гуи для этого вашего ффмпега не изобрели еще? чтоб не печатать 100 символов а сделать 5 кликов?
>>711655
Есть много гуев, но не очень то и нужно.
Есть много гуев, но не очень то и нужно.
>>686610 (OP)
webp lossless как замена .png? Годнота! Практически во всех случаях webp получается меньше, а в среднем процентов на 20%
.
webp lossy как замена .jpg? Хуета! Нет, не так, webp lossy - в принципе хуита. Даже на 100% проёбывает непозволительное количество информации и совершенно отвратительно работает с градиентами.
Так что в своей картинкпомойке перевел png в webp, а jpg различной степени сжатости пришлось оставить jpeg'ами разве что pingo'й прогнал.
webp lossless как замена .png? Годнота! Практически во всех случаях webp получается меньше, а в среднем процентов на 20%
.
webp lossy как замена .jpg? Хуета! Нет, не так, webp lossy - в принципе хуита. Даже на 100% проёбывает непозволительное количество информации и совершенно отвратительно работает с градиентами.
Так что в своей картинкпомойке перевел png в webp, а jpg различной степени сжатости пришлось оставить jpeg'ами разве что pingo'й прогнал.
>>711750
Соглы.
Разве что heif сейчас вполне доступен стараниями эпола. Для лосси он уже однозначно обходит жопег.
Соглы.
Разве что heif сейчас вполне доступен стараниями эпола. Для лосси он уже однозначно обходит жопег.
>>711814
xnconverter, сжатие на шестерочку.
xnconverter, сжатие на шестерочку.
>>711655
Мокрописьки не нужны. Почти все графические видеоредакторы/конверторы и есть гуи к ффмпег.
Мокрописьки не нужны. Почти все графические видеоредакторы/конверторы и есть гуи к ффмпег.
>>712559
Затем что вебп открывается?
Затем что вебп открывается?
В интернете встречаются картинки порой огромных размеров, таких как 7000х7000, которые очень долго декодируются на Core2duo.
Были перспективы за вейвлетными форматами, что например для отображения эскиза будет декодироваться маленькая часть файла, вместо декодирования всей картинки целиком, что не нужно будет создавать эскизные копии одного и того-же, что для отображения на экране 1024x768 будут декодироваться только часть картинки до 875х875, а не вся картинка целиком и декодироваться оно будет быстрее. Но что-то не влетело. Вместо этого появился jpeg2000, который опять разбивает картинку на блоки размеров в степени двойки, который долго кодируется и долго декодируется.
И вот на свет выходит FLIF, который хвастается своей прогрессивной загрузкой, которая суть всё тот-же ебаный интерлейсинг, который был ещё в гифках и png. Хочешь наделать эскизов? Декодируй картинку полностью нагружая CPU и забивая оперативку до свопа.
Были перспективы за вейвлетными форматами, что например для отображения эскиза будет декодироваться маленькая часть файла, вместо декодирования всей картинки целиком, что не нужно будет создавать эскизные копии одного и того-же, что для отображения на экране 1024x768 будут декодироваться только часть картинки до 875х875, а не вся картинка целиком и декодироваться оно будет быстрее. Но что-то не влетело. Вместо этого появился jpeg2000, который опять разбивает картинку на блоки размеров в степени двойки, который долго кодируется и долго декодируется.
И вот на свет выходит FLIF, который хвастается своей прогрессивной загрузкой, которая суть всё тот-же ебаный интерлейсинг, который был ещё в гифках и png. Хочешь наделать эскизов? Декодируй картинку полностью нагружая CPU и забивая оперативку до свопа.
>>712647
Современные кодеки ставят целью максимальное сжатие, а тобою описанное — залупа в колёсах. Тем более, сейчас в любом шаёми 8 вёдер и 4+ гб озу.
Современные кодеки ставят целью максимальное сжатие, а тобою описанное — залупа в колёсах. Тем более, сейчас в любом шаёми 8 вёдер и 4+ гб озу.
>>712647
просматривал свой пак картинок. Оказалось что aritmetic jpeg тормозит сильнее чем webp. Причём aritmetic jpeg тормозит на картинках если размер больше чем 1000х1000, а webp если больше чем 2500х2500. И еще мне показалось что lossless webp меньше лагает чем lossy webp
просматривал свой пак картинок. Оказалось что aritmetic jpeg тормозит сильнее чем webp. Причём aritmetic jpeg тормозит на картинках если размер больше чем 1000х1000, а webp если больше чем 2500х2500. И еще мне показалось что lossless webp меньше лагает чем lossy webp
>>711633
Ну и нахуй ты это говно советуешь? Рассинхрон будет, ебаный ты полудурок, блядь.
Ну и нахуй ты это говно советуешь? Рассинхрон будет, ебаный ты полудурок, блядь.
>>713070
Ага, стекломойной пидорахе лучше знать.
Ага, стекломойной пидорахе лучше знать.
8 Кб, 986x34Да походу av1 будет как и vp9 только в ютубе пользоваться таким темпами.
А hevc уже захватывает сердца.
А hevc уже захватывает сердца.
>>713112
Так имплементаций пока нет, и ускорение тонет. Если начнёт жать хотя бы 0,5 fps, тогда и появятся рипы.
Хевку тоже не один год понадобился.
Так имплементаций пока нет, и ускорение тонет. Если начнёт жать хотя бы 0,5 fps, тогда и появятся рипы.
Хевку тоже не один год понадобился.
>>713112
Так а чё ты хочешь?
Ты думаешь кто-то будет ждать кодека, который загружает 4 потока по дефолту, в то время как x265 загружает их все, как это было еще с x264. Да и знающему x264 проще освоить x265 чем libvpx-vp9.
Так а чё ты хочешь?
>libx265 slow 320k (55s)
>libvpx-vp9 320k (3m)
Ты думаешь кто-то будет ждать кодека, который загружает 4 потока по дефолту, в то время как x265 загружает их все, как это было еще с x264. Да и знающему x264 проще освоить x265 чем libvpx-vp9.
>>713112
ты забыл про двач с его webm-ками
ты забыл про двач с его webm-ками
771 Кб, 1920x1080>>686610 (OP)
Как можно было такую хуйню в продакшен пускать? Ёбаный стыд.
Как можно было такую хуйню в продакшен пускать? Ёбаный стыд.
>>713352
Я, к слову, о кодеке, потому что только их VP и ублюдочный WebP Lossy так хуёво работает с градиентами.
Я, к слову, о кодеке, потому что только их VP и ублюдочный WebP Lossy так хуёво работает с градиентами.
5 Кб, 259x194>>713352
Ты как блядь рубашку снял? Уноси своего скриптонита и таблетки прими.
Ты как блядь рубашку снял? Уноси своего скриптонита и таблетки прими.
>>713352
Битрейта небось не хватило, открой mp4 версию и там посмотри
Битрейта небось не хватило, открой mp4 версию и там посмотри
124 Кб, 1000x1000>>713352
Ну а чего вы хотели от 8-битного lossy кодека?
Начнем с того что 8 бит на канал недостаточно для отображения всех различимых оттенков даже человеческим глазом. Для сглаживания градиентов применяют костыль, который называется дизеринг. Дизеринг это подмешивание шума с минимально возможной для данной разрядности амплитудой, который создает субъективное ощущение большей разрядности.
Lossy кодеки ориентируются на сохранение деталей с большой амплитудой. ВЧ с малой амплитудой отбрасываются квантователем, то есть этот ваш дизеринг идет по пизде.
Ну а чего вы хотели от 8-битного lossy кодека?
Начнем с того что 8 бит на канал недостаточно для отображения всех различимых оттенков даже человеческим глазом. Для сглаживания градиентов применяют костыль, который называется дизеринг. Дизеринг это подмешивание шума с минимально возможной для данной разрядности амплитудой, который создает субъективное ощущение большей разрядности.
Lossy кодеки ориентируются на сохранение деталей с большой амплитудой. ВЧ с малой амплитудой отбрасываются квантователем, то есть этот ваш дизеринг идет по пизде.
3 Кб, 500x100>>713637
Чёрно-белые пнг с альфой коряво обрабатываются.
Чёрно-белые пнг с альфой коряво обрабатываются.
>>713635
В этом и пиздец. Кто в 2020 устраняет избыточность путём выпиливания ВЧ?
>Lossy кодеки ориентируются на сохранение деталей с большой амплитудой. ВЧ с малой амплитудой отбрасываются квантователем, то есть этот ваш дизеринг идет по пизде.
В этом и пиздец. Кто в 2020 устраняет избыточность путём выпиливания ВЧ?
>>714125
>jpeg живее всех живых
>практически все видеокодеки все еще занимаются DCT преобразованием, устраняют избыточность путём выпиливания ВЧ и блочат при нехватке битрейта
>адекватной замены гифкам нет до сих пор
>что-то спрашивать про 2020-й год
так то фотокамеры шумят достаточно сильно что-бы при сохранении в jpeg не заморачиватся с дизерингом.
А вот для рендеров и фотошопов нужен формат с разрядностью побольше.
А вот для рендеров и фотошопов нужен формат с разрядностью побольше.
862 Кб, 1000x664>>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)
>>714948
Мой шиндофон тот ещё суперкомпьютер. Но VLC увпшный, со старой либой, нет там av1.
Мой шиндофон тот ещё суперкомпьютер. Но VLC увпшный, со старой либой, нет там av1.
>>714940
Опус не может в 44100.
Опус не может в 44100.
>>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.
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.
>>714948
144p
240p
360p
480p
ffplay отказался воспроизводить av1 через libdav1d, поэтому применял костыли вида
До 360p воспроизводится нормально. На 480 есть тормоза (наверно из-за ремуксинга)
>для воспроизведения этого говнокодека нужен суперкопьютер.
>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
>>715766
Лол 480р уже тормозит, а что там с 1080р или 4к? Даже на i7 будет тормозить. Пусть гугл себе в одно место засунет этот тормозной говнокодек.
Лол 480р уже тормозит, а что там с 1080р или 4к? Даже на i7 будет тормозить. Пусть гугл себе в одно место засунет этот тормозной говнокодек.
>>715781
Видишь разницу между форматом видеокодека AV1 и декодером этого формата? libdav1d
Реализация гугла libaom-av1 декодит ещё хуже.
На i7 ничего не тормозит уже больше года, даже 4к.
https://forum.doom9.org/showthread.php?s=c9296846762f3daa7940cfa73d337f3d&p=1859793#post1859793
Видишь разницу между форматом видеокодека 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
>>715794
Достаточного одного ядра для воспроизведения vp9 4к, а для av1 нужно 4? Хочешь сказать, что это не говнокодек?
>ничего не тормозит
>-threads 4
Достаточного одного ядра для воспроизведения vp9 4к, а для av1 нужно 4? Хочешь сказать, что это не говнокодек?
>>715842
Довольно логично, что для воспроизведения кодека из 2018 не годится камень десятилетней давности.
Довольно логично, что для воспроизведения кодека из 2018 не годится камень десятилетней давности.
14 Кб, 512x512>>716008
Ага, новый, требовательный к железу кодек для них как бальзам на душу. Уже предчувствую батхерт васянов с коре дуо, когда его начнут вводить повсеместно. Чому видево про танки логает??
Ага, новый, требовательный к железу кодек для них как бальзам на душу. Уже предчувствую батхерт васянов с коре дуо, когда его начнут вводить повсеместно. Чому видево про танки логает??
>>716033
Пираты пользуется тем, что удобно для народа, а на остальное насрать.
>начнут вводить повсеместно
Пираты пользуется тем, что удобно для народа, а на остальное насрать.
>>716074
Действительно, с чего это неуловимого джо должны волновать проблемы 90% оставшегося население
Действительно, с чего это неуловимого джо должны волновать проблемы 90% оставшегося население
>>716069
>Ютубу так выгодно экономить на хранилище что кроме h264 + aac версий он еще кодирует и хранит vp9 версии и параллельно еще кодирует av1 для тестов.
>>716075
Да, совершенно насрать на анальные сервисы.
Да, совершенно насрать на анальные сервисы.
>>716077
Основное гемор - в поддержке CDN сети, а там только самые ходовые форматы хранят.
Основное гемор - в поддержке CDN сети, а там только самые ходовые форматы хранят.
>>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к и ноутбучная затычка вместо проца.
[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к и ноутбучная затычка вместо проца.
>>716106
Типо разные контейнеры, mkv и webm.
Типо разные контейнеры, mkv и webm.
>>716113
*Захватил
*Захватил
>>713359
Кстати да, VP9 на ютубе ублюдошно с темной частью градиентов работает, артефачит ее на каадраты. Я правда не могу быть уверен, что контентмейкер загрузил не уже в таком качестве
Кстати да, VP9 на ютубе ублюдошно с темной частью градиентов работает, артефачит ее на каадраты. Я правда не могу быть уверен, что контентмейкер загрузил не уже в таком качестве
>>713635
8 бит на канал кстати с дитхерингом просто прекрасно выглядит, даже повышение до 10 бит на канал ничего не дает визуально. Тут видать YUV 8 бит, а не RGB 8 бит потому что
8 бит на канал кстати с дитхерингом просто прекрасно выглядит, даже повышение до 10 бит на канал ничего не дает визуально. Тут видать YUV 8 бит, а не RGB 8 бит потому что
>>716033
Да никто так-то не выпилит fallback на H.264, ибо афони
Да никто так-то не выпилит fallback на H.264, ибо афони
>>716059
Ремухи UHD BD будут в том, в чем сами UHD BD, а это HEVC
Ремухи UHD BD будут в том, в чем сами UHD BD, а это HEVC
2716118
Не знаю, какую разницу ты увидел между yuv444p и rgb.
Но вот yuv420p снижает разрешение цветовых в 2 раза по высоте и ширине, а потому сетчатый узор на цветовых каналах в yuv420p будет заметнее чем просто в RGB.
У тебя 10 битный монитор и сигнал с видеокарты? Если нет, то в лучшем случае ты увидишь дизеринг.
Не знаю, какую разницу ты увидел между yuv444p и rgb.
Но вот yuv420p снижает разрешение цветовых в 2 раза по высоте и ширине, а потому сетчатый узор на цветовых каналах в yuv420p будет заметнее чем просто в RGB.
>даже повышение до 10 бит на канал ничего не дает
У тебя 10 битный монитор и сигнал с видеокарты? Если нет, то в лучшем случае ты увидишь дизеринг.
>>716128
Ну я не знаю на счет именно yuv444 - таких видосов раз-два и обчелся.
Да, и я с лупой проверял тестовый 10-битный пнг в мадвр. 8 бит с дитхерингом неотличимо от 10 бит с дитхерингом. Без дитхеринга да, легко отличимо.
> Не знаю, какую разницу ты увидел между yuv444p и rgb.
Ну я не знаю на счет именно yuv444 - таких видосов раз-два и обчелся.
> У тебя 10 битный монитор и сигнал с видеокарты?
Да, и я с лупой проверял тестовый 10-битный пнг в мадвр. 8 бит с дитхерингом неотличимо от 10 бит с дитхерингом. Без дитхеринга да, легко отличимо.
>>716698
Полтора часа в 20 мб! Я заинтересован. Можете пояснить залётному за все эти виды сжатия?
Полтора часа в 20 мб! Я заинтересован. Можете пояснить залётному за все эти виды сжатия?
>>716727
Современные кодеки и низкий битрейт: av1 - 20кб/с — видео и opus - 11кб/с — аудио. Ну и 16 часов кодирования.
Современные кодеки и низкий битрейт: av1 - 20кб/с — видео и opus - 11кб/с — аудио. Ну и 16 часов кодирования.
>>717783
Хотя да))
Хотя да))
а на русском конвертера для webm нема?
Как же хочеца HEIC, хоспаде.
Поигрался сейчас с HEIC через https://convertio.co/fr/ (Потому что мой Xn-Convert стабильно выплёвывает ошибку)
Оче круто.
Качественные изображения (пикрил 1) переводит практически без видимых потерь со значительным снижением веса.
Мусорные изображения (пикрил 3) также аккуратно переводит, но вес уже теряется просто пиздец как.
Оцениваю с точки зрения мемасной файлопомойки. так что требования небольшие - чтобы изображение на глаз осталось такое же, с градиентами (привет Webp Lossy) и цветами. Тут всё норм, различия ищу уткнувшись в экран, когда как с Webp всё было практически сразу видно - меня устраивает.
Из явных косяков - на одном из сложных JPG заметил, что он из ровных линий, делает квадратные (как будто понижение разрешения рендеринга в какой-нибудь игре), но были бы доступны крутилочки-вертелочки, думаю, можно было бы подобрать универсальный профиль.
Проблема лишь в том, что единственная программа, которая захотела его открыть это GIMP, а хочется повсеместного внедрения, чтобы и на телефон скинуть и на сайт.
Еще бы AV1 пощупать...
Поигрался сейчас с HEIC через https://convertio.co/fr/ (Потому что мой Xn-Convert стабильно выплёвывает ошибку)
Оче круто.
Качественные изображения (пикрил 1) переводит практически без видимых потерь со значительным снижением веса.
Мусорные изображения (пикрил 3) также аккуратно переводит, но вес уже теряется просто пиздец как.
Оцениваю с точки зрения мемасной файлопомойки. так что требования небольшие - чтобы изображение на глаз осталось такое же, с градиентами (привет Webp Lossy) и цветами. Тут всё норм, различия ищу уткнувшись в экран, когда как с Webp всё было практически сразу видно - меня устраивает.
Из явных косяков - на одном из сложных JPG заметил, что он из ровных линий, делает квадратные (как будто понижение разрешения рендеринга в какой-нибудь игре), но были бы доступны крутилочки-вертелочки, думаю, можно было бы подобрать универсальный профиль.
Проблема лишь в том, что единственная программа, которая захотела его открыть это GIMP, а хочется повсеместного внедрения, чтобы и на телефон скинуть и на сайт.
Еще бы AV1 пощупать...
1,7 Мб, 1920x1357Сап, сжимач, возникла такая ситуация. Имеется жёсткий диск, который заполнен лоли хентаем уже чуть менее чем полностью файлами всевозможных типов и форматов. Реквестирую как лучше всего имеющееся файлы перекодировать и сжать для минимального размера при сохранении качества или его минимальных потерях.
И что почитать чтобы разобраться в этой теме?
И что почитать чтобы разобраться в этой теме?
>>717980
This
https://css-ig.net/pingo
Настройки варьируются - lossless/небольшие потери/квадраты.
> при сохранении качества или его минимальных потерях.
This
https://css-ig.net/pingo
Настройки варьируются - lossless/небольшие потери/квадраты.
>>717984
Но это ведь только для фото. А у меня кроме их там и видео, и аудио, и текст, и даже несколько программ в портативных изданиях.
Алсо я не против перековырять всё вручную. Софт из оп поста пойдёт под любые медиаформаты? Как кодировать?
Но это ведь только для фото. А у меня кроме их там и видео, и аудио, и текст, и даже несколько программ в портативных изданиях.
Алсо я не против перековырять всё вручную. Софт из оп поста пойдёт под любые медиаформаты? Как кодировать?
>>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
> Софт из оп поста пойдёт под любые медиаформаты?
Да.
Видео кодируй с такими параметрами: -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
502 Кб, 2208x1242>>717971
У меня обратная задача - как смотреть с телефона в старой версии АЦДЦее (которая еще не полным калом была) никак
> чтобы и на телефон скинуть
У меня обратная задача - как смотреть с телефона в старой версии АЦДЦее (которая еще не полным калом была) никак
>>717995
>>717980
Медиа не сжимай, только текст, бинарники и подобное. Медиа и так в сжатом виде хранится, перекодируя не имея исходников ты просто получишь шакалов или ещё больший файл, в случае lossless. Всякие универсальные lossless алгоритмы, вроде lzma2, или даже жестокие алгоритмы семейства paq, поверх уже сжатых кодеками файлов дадут тебе парочку процентов.
>>717980
Медиа не сжимай, только текст, бинарники и подобное. Медиа и так в сжатом виде хранится, перекодируя не имея исходников ты просто получишь шакалов или ещё больший файл, в случае lossless. Всякие универсальные lossless алгоритмы, вроде lzma2, или даже жестокие алгоритмы семейства paq, поверх уже сжатых кодеками файлов дадут тебе парочку процентов.
>>717971
Ну, фиг знает.
По порядку:
png (6,43 МБ) -> heif (2,10 МБ) -> jpg (1,20 МБ).
Heif сохранял гимпом без потери качества.
Jpg c максимальным -quality 0 в ImageMagick.
Ну, фиг знает.
По порядку:
png (6,43 МБ) -> heif (2,10 МБ) -> jpg (1,20 МБ).
Heif сохранял гимпом без потери качества.
Jpg c максимальным -quality 0 в ImageMagick.
>>718248
По качество/размер jpg, очевидно, сосет.
heif (313 КБ) -> jpg (318 КБ).
Оба с 50% качеством сконвертированы.
По качество/размер jpg, очевидно, сосет.
heif (313 КБ) -> jpg (318 КБ).
Оба с 50% качеством сконвертированы.
147 Кб, 1903x892>>718253
Webp (320 КБ) тоже.
Webp (320 КБ) тоже.
>>718248
Про размер согласен. Кажется тот онлайн конвертер что-то мудрит. Позже пробовал переводить JPG в WebP и он каким-то образом выдавал результаты, которые были всегда меньше оригинала и при этом обработаны явно с помощью WebP Lossless, потому что характерных артефактов на градиентах не было.
При этом, когда я пробовал сжать эти же изображения с помощью нативной библиотеки cwebp результаты в WebP lossless всегда были в полтора-два раза больше, а схожий вес получался только с помощью WebP lossy, где всплывали видимые сразу же видимые артефакты.
Другими словами, как конвертер тот сайт очень хорош, но не объективен.
Еще, заметил, я думал, что это у меня из-за разницы вывода в гимпе и обычном картинкоменеджере - HEIC зеленит изображение, что довольно неприятно.
Про размер согласен. Кажется тот онлайн конвертер что-то мудрит. Позже пробовал переводить JPG в WebP и он каким-то образом выдавал результаты, которые были всегда меньше оригинала и при этом обработаны явно с помощью WebP Lossless, потому что характерных артефактов на градиентах не было.
При этом, когда я пробовал сжать эти же изображения с помощью нативной библиотеки cwebp результаты в WebP lossless всегда были в полтора-два раза больше, а схожий вес получался только с помощью WebP lossy, где всплывали видимые сразу же видимые артефакты.
Другими словами, как конвертер тот сайт очень хорош, но не объективен.
Еще, заметил, я думал, что это у меня из-за разницы вывода в гимпе и обычном картинкоменеджере - HEIC зеленит изображение, что довольно неприятно.
>>718261
Кстати, да. Гимп зеленит на выводе.
ImageMagick и gimp в png.
>HEIC зеленит изображение, что довольно неприятно.
Кстати, да. Гимп зеленит на выводе.
ImageMagick и gimp в png.
>>686610 (OP)
А?
>джипег как образчик сжатия на 10 из 10 по шкале ебучих шакалов
>ко-ко-ко-ко-пок-пок-порЭЭЭЭЭк унижаем пээнгэблидей!!!
А?
Какой положняк по кодекам и софту?
av1 > h265 > vp9 > h264
opus > vorbis > aac > mp3
heif > webp > jp2 > jpg
ffmpeg для видео и аудио.
convert из ImageMagick для изображений, но heif только чтение.
av1 > h265 > vp9 > h264
opus > vorbis > aac > mp3
heif > webp > jp2 > jpg
ffmpeg для видео и аудио.
convert из ImageMagick для изображений, но heif только чтение.
>>718362
Это ты создаёшь flac треды в /б?
Это ты создаёшь flac треды в /б?
>>718278
А, ну, если это чисто проблема GIMP'a, тогда формат хороший - одобряю.
Тогда положняк -
WebP Lossless - замена PNG.
HEIC/HEIF - замена JPG.
Ждём AV1
А, ну, если это чисто проблема GIMP'a, тогда формат хороший - одобряю.
Тогда положняк -
WebP Lossless - замена PNG.
HEIC/HEIF - замена JPG.
Ждём AV1
>>686650
На форчане до сих пор нет VP9 лол.
> когда сделают на фчане, абу запилит сюда через неделю-две. с вебмами так же было
На форчане до сих пор нет VP9 лол.
>>718332
aac строго лучше vorbis, vorbis имхо даже хуже mp3, но я накину ему за открытось
jp2 - маргинальщина, которой никогда не было
jpg и webp - примерно одного уровня, вопрос уровня "мыло или кубики", кому какие артефакты больше нравятся
avif очень потанцевальный формат, но в него вообще никто не умеет
Говнокомбайн. Только специализированные енкодеры и оптимизаторы.
aac строго лучше vorbis, vorbis имхо даже хуже mp3, но я накину ему за открытось
jp2 - маргинальщина, которой никогда не было
jpg и webp - примерно одного уровня, вопрос уровня "мыло или кубики", кому какие артефакты больше нравятся
avif очень потанцевальный формат, но в него вообще никто не умеет
>convert из ImageMagick
Говнокомбайн. Только специализированные енкодеры и оптимизаторы.
>>717971
Nomacs через костыли поддерживает, макос/шин10 умеет, последние мобилки в хейф по умолчания снимают.
Осталось только браузеры научить.
>Проблема лишь в том, что единственная программа, которая захотела его открыть это GIMP
Nomacs через костыли поддерживает, макос/шин10 умеет, последние мобилки в хейф по умолчания снимают.
Осталось только браузеры научить.
>>718396
Избыточными будут только часы перекодировки.
Избыточными будут только часы перекодировки.
>>718394
Удобно через консольку работать с нужными кодеками изображений. FFmpeg у тебя тоже говнокомбайн получается.
>>718437
Там пздц, конечно.
В мсторе hevc/heic платный, а бесплатная версия только если железо поддерживает (мне повезло с этим). Открывается все это либо через стандартное "Фотографии" (или др софт из мстора), который мылит картинку. Либо через тормозные костыли в каком-нибудь xnviewmp открывать.
Самая большая проблема в низкой распространенности новых форматов в приложениях и закрытом коде.
>Говнокомбайн
Удобно через консольку работать с нужными кодеками изображений. FFmpeg у тебя тоже говнокомбайн получается.
>>718437
>шин10 умеет
Там пздц, конечно.
В мсторе hevc/heic платный, а бесплатная версия только если железо поддерживает (мне повезло с этим). Открывается все это либо через стандартное "Фотографии" (или др софт из мстора), который мылит картинку. Либо через тормозные костыли в каком-нибудь xnviewmp открывать.
Самая большая проблема в низкой распространенности новых форматов в приложениях и закрытом коде.
Можете нормально пояснить несведующему анону про все эти ваши форматы и кодировки? Я сейчас вижу эту картину примерно так:
Фото
JPEG - качество средней паршивости, при сжатии шакалится
PNG - лучше чем предыдущий, но и места отжирает больше
WEBP - тот же джейпег, но меньше по размеру и сжимаясь размывается
HEIF - НЁХ, скорее всего замена пнг
Видео
Тут нихуя непонятно, но webm>>mp4
Кодеки
В этом тёмном лесу нихуя не ясно.
Аудио
MP3 - для лохов
OPUS - выбор мастеров
Фото
JPEG - качество средней паршивости, при сжатии шакалится
PNG - лучше чем предыдущий, но и места отжирает больше
WEBP - тот же джейпег, но меньше по размеру и сжимаясь размывается
HEIF - НЁХ, скорее всего замена пнг
Видео
Тут нихуя непонятно, но webm>>mp4
Кодеки
В этом тёмном лесу нихуя не ясно.
Аудио
MP3 - для лохов
OPUS - выбор мастеров
>>718555
Самое худшее качество
Идеальное качество, места естессно зрет стоко, скоко надо
Замена джейпегу, но бровзерами не поддерживается, так что на самом деле не замена
Это контейнеры, а не алгоритмы сжатия
Всё так
> Фото
> JPEG - качество средней паршивости, при сжатии шакалится
Самое худшее качество
> PNG - лучше чем предыдущий, но и места отжирает больше
Идеальное качество, места естессно зрет стоко, скоко надо
> WEBP - тот же джейпег, но меньше по размеру и сжимаясь размывается
> HEIF - НЁХ, скорее всего замена пнг
Замена джейпегу, но бровзерами не поддерживается, так что на самом деле не замена
> Видео
> Тут нихуя непонятно, но webm>>mp4
Это контейнеры, а не алгоритмы сжатия
> Кодеки
> В этом тёмном лесу нихуя не ясно.
> Аудио
> MP3 - для лохов
> OPUS - выбор мастеров
Всё так
>>718560
А видео примерно так, от плохого к хорошему:
MJPEG (в PS1 юзалось)
MPEG2
DivX
H.264/VC1
HEVC/VP9
AV1
А видео примерно так, от плохого к хорошему:
MJPEG (в PS1 юзалось)
MPEG2
DivX
H.264/VC1
HEVC/VP9
AV1
>>718560
Стоит отметить, что у WebP есть два типа сжатия - lossy и lossless (с потерями и без потерь соответственно).
WebP lossless подходит как охуенная замена png, поскольку абсолютно ничего не теряет, а размер ~на 20% меньше.
WebP lossy - ну такоооое. Вроде как замена jpg, но нужно пердолить конвертер ключами, чтобы получить нормальное изображение. HEIC в этом плане будет лучше, но он проприетарный, а значит дальше айфончиков особо не пойдет. Ждём внедрения AVIF.
Стоит отметить, что у WebP есть два типа сжатия - lossy и lossless (с потерями и без потерь соответственно).
WebP lossless подходит как охуенная замена png, поскольку абсолютно ничего не теряет, а размер ~на 20% меньше.
WebP lossy - ну такоооое. Вроде как замена jpg, но нужно пердолить конвертер ключами, чтобы получить нормальное изображение. HEIC в этом плане будет лучше, но он проприетарный, а значит дальше айфончиков особо не пойдет. Ждём внедрения AVIF.
К слову, почитал документацию cwebp и поэкспериментировал с ключами и вывел универсальную команду для перевода картинокомойки_jpg в картинкопомойку_webp (для png лучше всё же использовать lossless)
cwebp вход.jpg -sharp_yuv -jpeg_like -af -mt -sns 100 -o выход.webp
Самое важное и нужное. Замечал, что часто после перевода некоторые цвета теряют свою силу и сочность, что для меня лично не приемлемо в принципе. Это команда оставляет видимую палитру неизменной.
Оче годный ключ, который автоматически делает довольно качественную/детализированную картинку при этом равную по весу, либо меньше, чем оригинал (зачастую намного меньше). Позволяет избавиться от игры с ключом -q, что давал разные результаты для больших и малых изображений.
Автоматическая фильтрация - удаляет мелкие шероховатости после перекодировки.
Мультипоточность
Оставляет большую детализацию изображению совершенно не прибавляя в весе.
Сравнивал выход с ключом/без с максимальными/минимальными свойствами (-sns 100/-sns0) и итоговые ключи выдавали самую качественную картинку на мой взгляд.
В целом получается +- оригинальное качество, но намного меньший вес. Из минусов - большее время перекодировки, но не особо заметно на изображениях до двух мегабайт.
Дополнения приветсвуются.
cwebp вход.jpg -sharp_yuv -jpeg_like -af -mt -sns 100 -o выход.webp
>-sharp_yuv
Самое важное и нужное. Замечал, что часто после перевода некоторые цвета теряют свою силу и сочность, что для меня лично не приемлемо в принципе. Это команда оставляет видимую палитру неизменной.
>-jpeg_like
Оче годный ключ, который автоматически делает довольно качественную/детализированную картинку при этом равную по весу, либо меньше, чем оригинал (зачастую намного меньше). Позволяет избавиться от игры с ключом -q, что давал разные результаты для больших и малых изображений.
>-af
Автоматическая фильтрация - удаляет мелкие шероховатости после перекодировки.
>-mt
Мультипоточность
>-sns 100
Оставляет большую детализацию изображению совершенно не прибавляя в весе.
Сравнивал выход с ключом/без с максимальными/минимальными свойствами (-sns 100/-sns0) и итоговые ключи выдавали самую качественную картинку на мой взгляд.
В целом получается +- оригинальное качество, но намного меньший вес. Из минусов - большее время перекодировки, но не особо заметно на изображениях до двух мегабайт.
Дополнения приветсвуются.
>>718576
дважды пережимать с потерями? во сколько раз выигрыш в весе не написал даже.
> перевода картинокомойки_jpg в картинкопомойку_webp
дважды пережимать с потерями? во сколько раз выигрыш в весе не написал даже.
>>718560
Что значит не поддерживается?
https://caniuse.com/#feat=webp
Ничего что не поддерживают только ишак и сафари. А про KaiOS Browser кто нибудь вообще слышал?
>webp
>но бровзерами не поддерживается
Что значит не поддерживается?
https://caniuse.com/#feat=webp
Ничего что не поддерживают только ишак и сафари. А про KaiOS Browser кто нибудь вообще слышал?
Два .bmp шакалам в треде.
>>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 кб
Да, это я что-то на радостях написал от того, что удалось избавится от ужасных градиентов, но всё равно достаточно много деталей мылится, с 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 кб
>>718772
При этом довольно интересный эффект наблюдатся - на маленьких зашакаленных jpg webp наоборот делает лучше, убирая своим мылом мусорные квадраты png. собсна первые два пика релейтед.
При этом довольно интересный эффект наблюдатся - на маленьких зашакаленных jpg webp наоборот делает лучше, убирая своим мылом мусорные квадраты png. собсна первые два пика релейтед.
>>718772
через 10 лет еще что-то запилят, будешь третий раз её сжимать
> Конвертировать всю файлопомойку я не стал, подожду AVIF или HEIC.
через 10 лет еще что-то запилят, будешь третий раз её сжимать
>мусорные квадраты png
jpg разумеется. Надо идти спать.
>>718571
У пнг, имей ввиду, размер зависит от проги, сохраняющей его. В фотошопке самым маленьким получается
У пнг, имей ввиду, размер зависит от проги, сохраняющей его. В фотошопке самым маленьким получается
>>718698
Не-не, я это знаю, я токо про хеик писал, вебп предыдущей строкой при копировании просто осталось
Не-не, я это знаю, я токо про хеик писал, вебп предыдущей строкой при копировании просто осталось
>>718772
Хех первая в вебп даже лучше стала))
Хех первая в вебп даже лучше стала))
>>718775
Ага))
Ага))
>>720254
FLAC - пожатие аудио без потерь (lossless). Избыточен для 99% слушателей и только для отбитых аудиофилов.
MKV - контейнер, куда удобно запихать кучу дорожек аудио/субтитров. Развит в webm.
FLAC - пожатие аудио без потерь (lossless). Избыточен для 99% слушателей и только для отбитых аудиофилов.
MKV - контейнер, куда удобно запихать кучу дорожек аудио/субтитров. Развит в webm.
52 Кб, 1607x956Вы знаете, что miro-video-converter (https://github.com/pculture/mirovideoconverter3) очень круто сжимает!? И ещё вопрос, что это за порода собак?
362 Кб, webm,640x356, 0:03
>>720380
Когда кажется, нужно снизить дозу, если бы ты знал породу, то и не стал отвечать вопросом на ответ...
Когда кажется, нужно снизить дозу, если бы ты знал породу, то и не стал отвечать вопросом на ответ...
>>720377
Уникальный софт, достоин уровня /s.
>шкурка для ффмпег
>очень круто сжимает
>последний коммит 7 лет назад
Уникальный софт, достоин уровня /s.
7,5 Мб, webmА вообще самый крутой формат сжатия музла - трекерный лол. Типа .mod, .it, .xm, .s3m. Вот этот трек например в оригинале меньше 400 килобайт весит. Но есть нюанс...
Что там по ОПУСУ кстати слышно? Никаких обнов с апреля прошлого года. Всё, кодек уже допилили до идеала, ничего фиксить не надо?
>>720400
В трекерных очень всегда сухое звучание, без сложных ревербаций, мне не нравится, скушно такое слушать
В трекерных очень всегда сухое звучание, без сложных ревербаций, мне не нравится, скушно такое слушать
>>720409
Ну возьми "мокрые" семплы, в чем сложность? А ведь прикольная идея - кодировать исходный файл не сжатием, а реально конструированием и программированием, раскладывая его на семплы и скриптуя. Чтобы не человек в трекере сразу семплы набивал, а прога из стомегабайтной вавки сделала .mod на 300кб, неотличимый по звучанию от оригинала. Но для похожей хуйни наверно такие вычислительные мощности понадобятся, буквально суперкомп с ИИ. И один файл будет кодироваться сутки.
Ну возьми "мокрые" семплы, в чем сложность? А ведь прикольная идея - кодировать исходный файл не сжатием, а реально конструированием и программированием, раскладывая его на семплы и скриптуя. Чтобы не человек в трекере сразу семплы набивал, а прога из стомегабайтной вавки сделала .mod на 300кб, неотличимый по звучанию от оригинала. Но для похожей хуйни наверно такие вычислительные мощности понадобятся, буквально суперкомп с ИИ. И один файл будет кодироваться сутки.
>>720421
Да, норм идея
Да, норм идея
>>720464
Сойдёт для вкатывания новичков. Но для профи это НЕНУЖНО.
Сойдёт для вкатывания новичков. Но для профи это НЕНУЖНО.
>>720512
Это студийный юскейс. Флак в бытовом прослушивании никому не всрался.
>если нужно кодировать потом
Это студийный юскейс. Флак в бытовом прослушивании никому не всрался.
>>720464
В гну/линуксе почти на всё есть мокрописька на гтк, мокрописька на кьюте и мокрописька на нкурсес.
В гну/линуксе почти на всё есть мокрописька на гтк, мокрописька на кьюте и мокрописька на нкурсес.
>>720559
И аналог на расте и го.
И аналог на расте и го.
15 Кб, 475x130Посоны, что выбирать в такой ситуации кроме очевидного flac?
>>721593
Я сейчас выбираю для скачивания mp3. Потому что по дефолту сейчас везде стриминг пашет. А в нестандартных местах у mp3 выше всего шансы быть проигранными.
Я сейчас выбираю для скачивания mp3. Потому что по дефолту сейчас везде стриминг пашет. А в нестандартных местах у mp3 выше всего шансы быть проигранными.
>>721593
aac
aac
>>721678
Долго расшифровывал твой пост, а потом понял что ты просто зумерок со стримингом вместо hdd. Так зачем тебе вообще выбирать аудиокодек из раздач торрента?
Долго расшифровывал твой пост, а потом понял что ты просто зумерок со стримингом вместо hdd. Так зачем тебе вообще выбирать аудиокодек из раздач торрента?
>>722359
avif соответсвенно
avif соответсвенно
>>722368
Только вот приличных форматов векторной анимации нет со времён почившего флеша.
> вектор, а также векторные анимации это топ
Только вот приличных форматов векторной анимации нет со времён почившего флеша.
>>722359
А, я думал про анимэ
А, я думал про анимэ
>>722245
Как что-то плохое. Цивилизация даёт блага - пользуйся. Нет хотим газку поддавать.
>стримингом вместо hdd
Как что-то плохое. Цивилизация даёт блага - пользуйся. Нет хотим газку поддавать.
>>723110
А вот тут ты обосрался. Он модульный, перед компиляцией можно выбрать нужный функционал и исключить лишнее.
>Что значит получается? Всегда им был и остается.
А вот тут ты обосрался. Он модульный, перед компиляцией можно выбрать нужный функционал и исключить лишнее.
Какой формат самый эффективный для хранения документов? На форматирование строго похуй.
.txt или .md?
.txt или .md?
>>724803
Зачем, когда обычный ASCII файл открывается практически на любой системе очень большим количеством программ.
Зачем, когда обычный ASCII файл открывается практически на любой системе очень большим количеством программ.
18 Кб, 980x238>>724824
Запили раздел на бтрфс со сжатием zstd.
>Хочется сферического пожатия в вакууме. Экономия места и с нынешними мощностями мгновенно все будет с каким-нибудь открытым методом с хорошими место/скорость показателями. Ясен пень не паком, эти 22Мб 17мин жались.
Запили раздел на бтрфс со сжатием zstd.
>>724708
.7z
.7z
Можно в ffmpeg как-нибудь предсказать размер, исходя из параметров и соуса, видео до ожидания 100500 часов кодирования?
>>731217
зависит от формата, но в случае h264/h265 работает такая формула
((bv + ba) * t) / 8192
bv - битрейт видео (bps)
ba - битрейт аудио (bps)
t - продолжительность видео (s)
зависит от формата, но в случае h264/h265 работает такая формула
((bv + ba) * t) / 8192
bv - битрейт видео (bps)
ba - битрейт аудио (bps)
t - продолжительность видео (s)
>>731436
Спасибо. Но битрейт видео какой вписывать, если он постоянно прыгает?
А для vp9 есть что-нибудь подобное? Приходится с разными -crf в 3-4 потока одновременно запускать кодирование того же видео (все равно vp9 не полностью проц нагружает, как h264).
Алсо, тут пробовал сравнить гпу кодирование с h264_nvenc и обычный h264, но получаются совершенно разные результаты с командами, отличающимися только этими кодеками.
Спасибо. Но битрейт видео какой вписывать, если он постоянно прыгает?
А для vp9 есть что-нибудь подобное? Приходится с разными -crf в 3-4 потока одновременно запускать кодирование того же видео (все равно vp9 не полностью проц нагружает, как h264).
Алсо, тут пробовал сравнить гпу кодирование с h264_nvenc и обычный h264, но получаются совершенно разные результаты с командами, отличающимися только этими кодеками.
325 Кб, 800x800>>686610 (OP)
Аноны, как сжимать аудио через libvorbis, чтобы конечный файл был без видеопотока? Сжимаю коммандой:
ffmpeg -i 1.m4a -c:a libvorbis -q:a 0 1.ogg
но почему-то на телефоне открывается, как видео. Как исправить?
Аноны, как сжимать аудио через libvorbis, чтобы конечный файл был без видеопотока? Сжимаю коммандой:
ffmpeg -i 1.m4a -c:a libvorbis -q:a 0 1.ogg
но почему-то на телефоне открывается, как видео. Как исправить?
>>731916
Я ебан. Нужно ставить флаг '-vn', чтобы отключить видеопоток.
Я ебан. Нужно ставить флаг '-vn', чтобы отключить видеопоток.
>>686610 (OP)
Не уверен, правильный ли тред, но ладно.
Монтирую видео (оригинал в H265) в премьере и превьюха в премьере жестко тормозит на i7 2600, что аж невозможно. В всмысле, на ноутбуке ryzen 3700u она меньше тормозит, хотя ноутбук очевидно слабее.
Не уверен, правильный ли тред, но ладно.
Монтирую видео (оригинал в H265) в премьере и превьюха в премьере жестко тормозит на i7 2600, что аж невозможно. В всмысле, на ноутбуке ryzen 3700u она меньше тормозит, хотя ноутбук очевидно слабее.
>>731948
Дополню, что на ноуте ссд, а на компе проект находится на хдд, может ли это как-то влиять?
Дополню, что на ноуте ссд, а на компе проект находится на хдд, может ли это как-то влиять?
>>731948
Ну ты пони. Во-первых, да, SSD может влиять. Во-вторых, 2700k, при всём уважении к Sandy Bridge, монтаж h.265 просто не тащит, как бы ни было горько это признавать.
>H265
>i7 2600
Ну ты пони. Во-первых, да, SSD может влиять. Во-вторых, 2700k, при всём уважении к Sandy Bridge, монтаж h.265 просто не тащит, как бы ни было горько это признавать.
>>731983
Жалко. Все-таки удивительно, что ноутбучный процессор 4/8 на 15 ватт справляется лучше, чем десктопный 4/8 большей частоты на 90 ватт.
Жалко. Все-таки удивительно, что ноутбучный процессор 4/8 на 15 ватт справляется лучше, чем десктопный 4/8 большей частоты на 90 ватт.
>>731996
Ничего удивительного. У кукурузера, емнип, аппаратная поддержка декодирования h.265. Годы никого не щадят.
Ничего удивительного. У кукурузера, емнип, аппаратная поддержка декодирования h.265. Годы никого не щадят.
>>732010
Пизда
Пизда
>>723859
а куда оригиналы делись? экспорт данных гугла выдаёт оригиналы, как минимум 8-летние оригиналы ещё целы
а куда оригиналы делись? экспорт данных гугла выдаёт оригиналы, как минимум 8-летние оригиналы ещё целы
Не тонем
84 Кб, 1280x720Стандарт AVIF вроде окончательно принят, а никакой софт до сих пор в него не умеет или я плохо искал? Особенно интересно насколько лучше lossless сжатие в сравнении с webp
>>737331
Это. Только очень эпизодические звери.
Все новые форматы фокусируются вокруг удаления избыточности. Нечё от них лослесс побед ждать. Юзай специализированный flif.
> софт до сих пор в него не умеет
Это. Только очень эпизодические звери.
>lossless сжатие
Все новые форматы фокусируются вокруг удаления избыточности. Нечё от них лослесс побед ждать. Юзай специализированный flif.
>>737361
А где же поддержка всеми мировыми корпорациями, где же попенсорс с гитхаб-бинарниками от васянов...
У меня не взлетел, при конвертации полноэкранных пнг скриншотов во флиф файлы в основном были немного больше чем вебп лосслес. Последний к тому же быстрее открывается и имеет превьюшки в проводнике дриснятки. Для перегона юзал XnConvert, возможно там не те либы и можно получить результат получше
А где же поддержка всеми мировыми корпорациями, где же попенсорс с гитхаб-бинарниками от васянов...
>FLIF
У меня не взлетел, при конвертации полноэкранных пнг скриншотов во флиф файлы в основном были немного больше чем вебп лосслес. Последний к тому же быстрее открывается и имеет превьюшки в проводнике дриснятки. Для перегона юзал XnConvert, возможно там не те либы и можно получить результат получше
>>737331
https://github.com/AOMediaCodec/av1-avif/wiki
пока мало что, да и то не всегда нормально работает, можно еще руками через Aomenc сжимать и потом муксить MP4Box
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
Его автор уже пару лет помогает делать 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/
>или я плохо искал?
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/
Зачем аноны хотят перекодировать свои паки с трапами в новый формат, если при каждом перекодировании качество ухудшается?
>>739944
Потому что аноны идиоты.
Потому что аноны идиоты.
Ничего не понимаю в этих шакалах.
Возможно на одном и том же видеотреке некоторую часть выполнить с большим качеством? Например, есть ролик с записью от видеорегистратора, где не очень важен некоторый тайминг перед аварийной ситуацией, но нужен для общей ситуации, а в некоторый момент качество увеличивается.
Возможно на одном и том же видеотреке некоторую часть выполнить с большим качеством? Например, есть ролик с записью от видеорегистратора, где не очень важен некоторый тайминг перед аварийной ситуацией, но нужен для общей ситуации, а в некоторый момент качество увеличивается.
Как сделать чтобы youtube-dl скачивал bestaudio и bestvideo, а потом ffmpeg склеивал это все в mp4/webm. а то у меня все в mkv склеивается
>>740227
thx, anon
thx, anon
>>740170
Делить на части, кодировать, склеивать.
Делить на части, кодировать, склеивать.
113 Кб, 824x662>>740170
--zones в x264
У ffmpeg можно квантование на лету менять, но я не помню как, слишком давно это было.
--zones в x264
У ffmpeg можно квантование на лету менять, но я не помню как, слишком давно это было.
>>741186
BPG - мертворождён, можешь забыть про него.
Вместо него, с лёгкой руки эппла, пришёл по сути тот же HEIF.
И конечно же WebP проигрывает HEIF во многом. Во многом, кроме распространённости и поддержки в ПО.
>с BPG
BPG - мертворождён, можешь забыть про него.
Вместо него, с лёгкой руки эппла, пришёл по сути тот же HEIF.
И конечно же WebP проигрывает HEIF во многом. Во многом, кроме распространённости и поддержки в ПО.
>>741191
Так-то WebP тоже. К тому времени когда его поддержку добавят везде и им даже начнут пользоваться люди он станет ненужен из-за ширины канала и возможностей железа юзать повсеместно PNG, а аппаратная поддержка JPG с его производными типа JPEG XR, JPEG-LS и JPEG2000 делают жопег и вовсе неубиваемым в обозримом будущем, это говно не утонет, прост в настройках шакалирование будут меньше пользовать. WebP мертворождённое говно, в попытке "пожать" сделали говнище, которое в затратах процессорного времени соревнуется с полноценными lossles (и обгоняет их), при этом ещё и качества не даёт.
>BPG - мертворождён
Так-то WebP тоже. К тому времени когда его поддержку добавят везде и им даже начнут пользоваться люди он станет ненужен из-за ширины канала и возможностей железа юзать повсеместно PNG, а аппаратная поддержка JPG с его производными типа JPEG XR, JPEG-LS и JPEG2000 делают жопег и вовсе неубиваемым в обозримом будущем, это говно не утонет, прост в настройках шакалирование будут меньше пользовать. WebP мертворождённое говно, в попытке "пожать" сделали говнище, которое в затратах процессорного времени соревнуется с полноценными lossles (и обгоняет их), при этом ещё и качества не даёт.
>>731948
Даже без учёта того, что у 3700u аппаратная поддержка H265 в видеоядре, он на клыка сэндику даёт. Там блядь оперативная память в два раза почти шустрее, инструкции новые и старый Гипертрединг времён Сэндика на фоне Скалейковского и Рузеновского гипертреда это говно.
>Монтирую видео (оригинал в H265) в премьере и превьюха в премьере жестко тормозит на i7 2600, что аж невозможно. В всмысле, на ноутбуке ryzen 3700u она меньше тормозит, хотя ноутбук очевидно слабее.
Даже без учёта того, что у 3700u аппаратная поддержка H265 в видеоядре, он на клыка сэндику даёт. Там блядь оперативная память в два раза почти шустрее, инструкции новые и старый Гипертрединг времён Сэндика на фоне Скалейковского и Рузеновского гипертреда это говно.
Я сжал.
>>741201
Она сегодня и есть практически везде.
А вот у этих нет и никогда не появится. Вот и вся история.
>К тому времени когда его поддержку добавят везде
Она сегодня и есть практически везде.
>поддержка JPG с его производными типа JPEG XR, JPEG-LS и JPEG2000
А вот у этих нет и никогда не появится. Вот и вся история.
11 Кб, 846x111>>741219
1. Если бы работал в веб макакинге, то знал бы, что он практически нигде не используется.
2. Я больше скажу, сам гугл в рот ебал свой WebP, используя исключительно SVG, PNG и JPG на своих сервисах, проще говоря, WebP не нужен даже Гулагу. Вот тебе пруф, можешь сам отинспектировать сервисы гугла, везде svg и png.
3. А теперь самое смешное, основное применение WebP по состоянию на 2020 год это пережатие уже уебански шакальных jpg с сайтов для онлайн конвертации и отдаче юзеру через CDN.
4. Apple Safari.
>Она сегодня и есть практически везде.
1. Если бы работал в веб макакинге, то знал бы, что он практически нигде не используется.
2. Я больше скажу, сам гугл в рот ебал свой WebP, используя исключительно SVG, PNG и JPG на своих сервисах, проще говоря, WebP не нужен даже Гулагу. Вот тебе пруф, можешь сам отинспектировать сервисы гугла, везде svg и png.
3. А теперь самое смешное, основное применение WebP по состоянию на 2020 год это пережатие уже уебански шакальных jpg с сайтов для онлайн конвертации и отдаче юзеру через CDN.
4. Apple Safari.
>>741223
Он его для юзер-контента использует, превьюшки на ютубе, картинки/иконки в плейсторе
> сам гугл в рот ебал свой WebP
Он его для юзер-контента использует, превьюшки на ютубе, картинки/иконки в плейсторе
10 Кб, 752x106>>741226
Лол, нет.
Иконки - да. Часть картинки обложки, наложения кнопок плей и т.п. png.
>превьюшки на ютубе
Лол, нет.
>картинки/иконки в плейсторе
Иконки - да. Часть картинки обложки, наложения кнопок плей и т.п. png.
>>741223
Яндекс отдаёт предпросмотр картинок в webp, например.
Яндекс отдаёт предпросмотр картинок в webp, например.
79 Кб, 368x442>>741227
А в плейсторе он оказывается отдает хрому вебп, а лисе пнг. Хотя с тем что вебп нинужен я согласен.
А в плейсторе он оказывается отдает хрому вебп, а лисе пнг. Хотя с тем что вебп нинужен я согласен.
>>741205
А что изменилось? По сравнению с смт все такое же сендиговно.
> Гипертрединг времён Сэндика на фоне Скалейковского
А что изменилось? По сравнению с смт все такое же сендиговно.
Для avif теперь выкладывают билды под винду, плюс завезли поддержку png https://ci.appveyor.com/project/louquillio/libavif/build/artifacts
Анон в /a/ помню год назад скидывал Evangelion 1.11 влезающий в 40 Mb двача, и при этом это можно было даже смотреть, фильм на полтора часа. Есть у кого этот файл?
>>749614
Помню, что ширина кадра была аж 350
Помню, что ширина кадра была аж 350
Что то странное происходит с 251-м opus на youtube.
Как то раз, загрузил на youtube flac, он его тогда пережал в aac, ну ничего особенного от этого формата я и не ожидал. Потом я забыл про то видео и пережал для себя тот флак в opus vbr 144k.
Теперь youtube кодирует vp9/opus версии. И на том видео тоже появилась opus версия. Ну думаю, ща посмотрю на спектры со всеми 20 килогерцами. Ага, щас! Ютуб их зачемто взял и порезал. Этот срез похож на mp3, но нехарактерный для opus. Те остатки которые видны на спектрограмме можно списать на недоработку lowpass фильтра.
Главный вопрос: Зачем? Зачем они приравняли частотный диапазон к aac версии трека? Это они так пытаются продвигать свои сервисы "Youtube music" или "Google Play Music"?
Как то раз, загрузил на youtube flac, он его тогда пережал в aac, ну ничего особенного от этого формата я и не ожидал. Потом я забыл про то видео и пережал для себя тот флак в opus vbr 144k.
Теперь youtube кодирует vp9/opus версии. И на том видео тоже появилась opus версия. Ну думаю, ща посмотрю на спектры со всеми 20 килогерцами. Ага, щас! Ютуб их зачемто взял и порезал. Этот срез похож на mp3, но нехарактерный для opus. Те остатки которые видны на спектрограмме можно списать на недоработку lowpass фильтра.
Главный вопрос: Зачем? Зачем они приравняли частотный диапазон к aac версии трека? Это они так пытаются продвигать свои сервисы "Youtube music" или "Google Play Music"?
>>755947
Куда? В nomacs?
Куда? В nomacs?
А есть для опуса какие-нибудь костыли, которые анализируют mp3шный трек и исходя из его битрейта, частот и энтропии сами выбирают пресет для сжатия типа "чтоб примерно так же осталось"?
>>749772
Нет, они похожи именно на мр3 стайл оставление только самых громких пиков свыше 16 КГц
> Те остатки которые видны на спектрограмме можно списать на недоработку lowpass фильтра.
Нет, они похожи именно на мр3 стайл оставление только самых громких пиков свыше 16 КГц
>>756376
Хех, мда. А не лучше будет скачать желаемый музон в флак, а потом пережать в опус желаемого битрейта? Избежишь двойной потери качества
Хех, мда. А не лучше будет скачать желаемый музон в флак, а потом пережать в опус желаемого битрейта? Избежишь двойной потери качества
>>756387
Почему ты решил что это музыка, и что она существует в каком-то другом экземпляре? Двач ты не меняешься.
Это архивные записи разговоров, при том в огромном количестве, из разных источников и с разным качеством.
Я конечно могу засесть на две недели со слепым тестированием и подбором битрейта. Но хочется один такой ключик типа -mp3_like как тут >>718772 который примерно оставит всё как есть, но позволит занимать меньше места.
Почему ты решил что это музыка, и что она существует в каком-то другом экземпляре? Двач ты не меняешься.
Это архивные записи разговоров, при том в огромном количестве, из разных источников и с разным качеством.
Я конечно могу засесть на две недели со слепым тестированием и подбором битрейта. Но хочется один такой ключик типа -mp3_like как тут >>718772 который примерно оставит всё как есть, но позволит занимать меньше места.
>>756296
lowpass фильтры не идеальны, и при громких пиках они оставляют мусор в спектре они не полностью их подавляют, так что они остаются в спектре с приглушенной амплитудой.
В принципе, их можно подавить средствами самого кодировщика, путем подбора квантователя для соответсвующей полосы частот так, что-бы этот мусор остался за порогом округления, но qaac почему-то этого не сделал.
А opus еще на 32-х килобитах в секунду пытается закодировать весь диапазон. А поскольку после lowpass фильтр не идеален и оставил после себя мусор, то opus взял и закодировал его как смог.
Для примера 2-й пикрелейтед mp3 320kbps. Здесь видно что спектр отфильтрован, но оставшийся сигнал имеет примерно ту-же громкость мощность, энергия, как оно правильно называется?, что и сигнал с другой полосы частот. Это и отличает фильтр в mp3 от просто lowpass фильтра.
А теперь снова посмотри на ту спектрограмму ютубовского опуса. Там сигнал в самой высокочастотной полосе частот тише основного спектра, что является признаком применения именно lowpass фильтра перед кодированием, а не фильтрации высокобитрейтного mp3.
lowpass фильтры не идеальны, и при громких пиках они оставляют мусор в спектре они не полностью их подавляют, так что они остаются в спектре с приглушенной амплитудой.
В принципе, их можно подавить средствами самого кодировщика, путем подбора квантователя для соответсвующей полосы частот так, что-бы этот мусор остался за порогом округления, но qaac почему-то этого не сделал.
А opus еще на 32-х килобитах в секунду пытается закодировать весь диапазон. А поскольку после lowpass фильтр не идеален и оставил после себя мусор, то opus взял и закодировал его как смог.
Для примера 2-й пикрелейтед mp3 320kbps. Здесь видно что спектр отфильтрован, но оставшийся сигнал имеет примерно ту-же громкость мощность, энергия, как оно правильно называется?, что и сигнал с другой полосы частот. Это и отличает фильтр в mp3 от просто lowpass фильтра.
А теперь снова посмотри на ту спектрограмму ютубовского опуса. Там сигнал в самой высокочастотной полосе частот тише основного спектра, что является признаком применения именно lowpass фильтра перед кодированием, а не фильтрации высокобитрейтного mp3.
>>756280
>>756354
Ты видимо не шаришь. 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.
>>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.
>>756488
Цифровые - идеальны)
Ну он даже на 144 кбит/с на ютубе режет под 20 КГц (по моим тестам в фирефох-треде) (притом полный диапазон - 24 КГц)
Хотя да, но ослабление громкости слишком слабое
> lowpass фильтры не идеальны
Цифровые - идеальны)
> А opus еще на 32-х килобитах в секунду пытается закодировать весь диапазон
Ну он даже на 144 кбит/с на ютубе режет под 20 КГц (по моим тестам в фирефох-треде) (притом полный диапазон - 24 КГц)
> посмотри на ту спектрограмму ютубовского опуса. Там сигнал в самой высокочастотной полосе частот тише основного спектра, что является признаком применения именно lowpass фильтра перед кодированием, а не фильтрации высокобитрейтного mp3.
Хотя да, но ослабление громкости слишком слабое
>>686610 (OP)
Хули толку. Большинство этих форматов здохнет, как и все технически более совершенные «убийцы» mp3, jpg, rar и т.д. Популярность и распространённость — вот что действительно важно.
Всем этим 7zip-ам, опусам и прочему jpeg2000 вечно ютиться на задворках интернетов, поддерживаемые на искусственной вентиляции лёгких силами трёх с половиной задротов. Мне, разумеется, тоже не нравится эта ситуация, когда привычка стоит на пути прогресса, но хули делать.
Хули толку. Большинство этих форматов здохнет, как и все технически более совершенные «убийцы» mp3, jpg, rar и т.д. Популярность и распространённость — вот что действительно важно.
Всем этим 7zip-ам, опусам и прочему jpeg2000 вечно ютиться на задворках интернетов, поддерживаемые на искусственной вентиляции лёгких силами трёх с половиной задротов. Мне, разумеется, тоже не нравится эта ситуация, когда привычка стоит на пути прогресса, но хули делать.
>>756561
heif - дефолтный формат айфонов, поддерживается практически всеми ОС. Как только браузеры научатся - вот тебе и наступит новый жипег.
>Популярность и распространённость — вот что действительно важно.
heif - дефолтный формат айфонов, поддерживается практически всеми ОС. Как только браузеры научатся - вот тебе и наступит новый жипег.
>>756564
HEVC не поддерживают принципиально. А HEIF, обертку под HEVC для картинок, значит поддержат?
HEVC не поддерживают принципиально. А HEIF, обертку под HEVC для картинок, значит поддержат?
28 Кб, 596x187>>756559
у него нет режима 44100кГц, поэтому он ресемплит до 48кГц.
а срез 20кГц на всех битрейтах (за исключением самых низких) это у него по дефолту.
Смотря какой фильтр. Вот lowpass фильтр у Audacity там срез максимум 48 децибел на октаву. Приходится многократно повторять этот фильтр,что-бы действительно срезать ВЧ.
>притом полный диапазон - 24 КГц
у него нет режима 44100кГц, поэтому он ресемплит до 48кГц.
а срез 20кГц на всех битрейтах (за исключением самых низких) это у него по дефолту.
>Цифровые - идеальны
Смотря какой фильтр. Вот lowpass фильтр у Audacity там срез максимум 48 децибел на октаву. Приходится многократно повторять этот фильтр,что-бы действительно срезать ВЧ.
>>756576
В Аудишне FFT фильтр начисто срезает, если настроить соответствующе. И отдельный low-pass filter есть вроде бы
В Аудишне FFT фильтр начисто срезает, если настроить соответствующе. И отдельный low-pass filter есть вроде бы
>>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, чисто за частоту дискретизации спрашиваю.
А почему его должны часто обновлять? Тулсы вообще по несколько лет обновляются, 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, чисто за частоту дискретизации спрашиваю.
>>762296
Ну самый свежий из lossy вроде, только в 2012 формат запилили.
> почему его должны часто обновлять
Ну самый свежий из lossy вроде, только в 2012 формат запилили.
>>762301
Гуглить то хоть пробовал? Никуда не делся твой opus, развивается.
https://git.xiph.org/?p=opus.git
https://git.xiph.org/?p=opus.git;a=log
Гуглить то хоть пробовал? Никуда не делся твой opus, развивается.
https://git.xiph.org/?p=opus.git
https://git.xiph.org/?p=opus.git;a=log
>>762296
Ну в сам opusenc встроен ресемплер. Но если сомневаешься в его качестве, можешь и через sox перегнать.
Передискретизация, с учетом неидевльности lowpass фильтров, может вносить дополнительные искажения. Только вот являются ли они существенными при lossy компрессии?
По умалчанию opusdec такой сигнал снова отресемплит до 44100 Гц. А вот foobar2000 будет воспроизводить в 48 кГц без ресемплинга.
Ещё учти что звуковуха может нативно не поддержитать 44100 Гц. Тогда ей всё равно понадобится ресемплер.
Ну в сам opusenc встроен ресемплер. Но если сомневаешься в его качестве, можешь и через sox перегнать.
Передискретизация, с учетом неидевльности lowpass фильтров, может вносить дополнительные искажения. Только вот являются ли они существенными при lossy компрессии?
По умалчанию opusdec такой сигнал снова отресемплит до 44100 Гц. А вот foobar2000 будет воспроизводить в 48 кГц без ресемплинга.
Ещё учти что звуковуха может нативно не поддержитать 44100 Гц. Тогда ей всё равно понадобится ресемплер.
>>762657
Все звуковухи реалтек передискретизируют всё аудио в 48 КГц, если в панели 48 стоит, насколько я понимаю.
> Ещё учти что звуковуха может нативно не поддержитать 44100 Гц
Все звуковухи реалтек передискретизируют всё аудио в 48 КГц, если в панели 48 стоит, насколько я понимаю.
>>762961
Во-первых лосслес в плане математики ультрапримитивен, там всё изобрели уже 30 лет назад. Чё его в 2к20 обсуждать?
Во-вторых, в 2k20 основной потребитель контента - это мобилки, где размер хранилища определяется маркетингом а не техпроцессами. Да даже компы сейчас стараются укомплектовывать ссд, а данные выносить на насы. Так что сжатие в 2к20 - более чем актуальная тема.
Во-первых лосслес в плане математики ультрапримитивен, там всё изобрели уже 30 лет назад. Чё его в 2к20 обсуждать?
Во-вторых, в 2k20 основной потребитель контента - это мобилки, где размер хранилища определяется маркетингом а не техпроцессами. Да даже компы сейчас стараются укомплектовывать ссд, а данные выносить на насы. Так что сжатие в 2к20 - более чем актуальная тема.
Как вам сжатие в тик токе?
>>763227
Я тебе про ситуацию в экосистеме, а ты мне ad hominem про одного человека. Давай вкатывайся в формальную логику, пока не поздно.
Я тебе про ситуацию в экосистеме, а ты мне ad hominem про одного человека. Давай вкатывайся в формальную логику, пока не поздно.
>>763366
Модус поненс
Модус поненс
>>763468
На самом деле в 2017 году за 42К айфон имел 32 ГБ (и их не расширить MicroSD), а за 16К Сяоми - 64 ГБ, так что это айфоны обделены хранилищем
На самом деле в 2017 году за 42К айфон имел 32 ГБ (и их не расширить MicroSD), а за 16К Сяоми - 64 ГБ, так что это айфоны обделены хранилищем
>>763468
Ни в один флагман не удастся всунуть десяток терайбат, как в старую добрую пеку. Потому с раземером в любом случае приходится считаться.
Ни в один флагман не удастся всунуть десяток терайбат, как в старую добрую пеку. Потому с раземером в любом случае приходится считаться.
979 Кб, 1000x1000>>762657
Вижу ты хорошо шаришь. Не мог бы пояснить еще пару моментов с PCM? С такими вопросами ньюфажин аудиофилы сразу гонят тряпками.
1) Достаточно ли ужимать 24-битные PCM в 16-битный PCM с обычным дизерингом фубара или нужны обязательно всякие нойзшепинги дополнительно для такого?
2) При конвертировании PCM Aiff в PCM Wav идентичной битности теряется ли качество? И тоже нужны ли в таких случаях конвертирования всякие дизеринги и тд/тп?
Вижу ты хорошо шаришь. Не мог бы пояснить еще пару моментов с PCM? С такими вопросами ньюфажин аудиофилы сразу гонят тряпками.
1) Достаточно ли ужимать 24-битные PCM в 16-битный PCM с обычным дизерингом фубара или нужны обязательно всякие нойзшепинги дополнительно для такого?
2) При конвертировании PCM Aiff в PCM Wav идентичной битности теряется ли качество? И тоже нужны ли в таких случаях конвертирования всякие дизеринги и тд/тп?
>>766418
Я неон, но по 1) скажу, что твоя пекарня издает такой шум, что динамического диапазона 96 дБ даже с дитхерингом без нойз шейпинга выше крыши будет, ты весь этот диапазон не услышишь в условиях существенного фонового шума.
Я неон, но по 1) скажу, что твоя пекарня издает такой шум, что динамического диапазона 96 дБ даже с дитхерингом без нойз шейпинга выше крыши будет, ты весь этот диапазон не услышишь в условиях существенного фонового шума.
>>766464
Только непонятно, зачем ужимать, у тебя звуковуха только вывод 16 бит что ли поддерживает? 24 нет?
Только непонятно, зачем ужимать, у тебя звуковуха только вывод 16 бит что ли поддерживает? 24 нет?
>>766464
Точнее, благодаря дитхерингу динамический диапазон даже больше, это уровень шума на -96 дБ
Точнее, благодаря дитхерингу динамический диапазон даже больше, это уровень шума на -96 дБ
257 Кб, 1200x900>>686610 (OP)
Но WebP на четвертой объективно хуже. У него же даже морщины разгладились, неужели ты этого не видишь? Типичная ошибка новичка в шакалинге - мыло вместо частичного сохранения деталей.
Но WebP на четвертой объективно хуже. У него же даже морщины разгладились, неужели ты этого не видишь? Типичная ошибка новичка в шакалинге - мыло вместо частичного сохранения деталей.
>>766466
Да просто экономия места, музыки пиздец уже, в облако кидаю не часто прослушиваемые жанры. У меня интернет еще не особо то быстрый, выкачивать потом эти 24, я смысла в них особого не вижу, мне мастерингом не заниматься, бутлегов писать не планирую. А если нужно побаловаться, то всегда можно достать их из первоисточника, в данном случае Bandcamp.
https://bandcamp.com/fossf1/following/genres
https://bandcamp.com/fossf1/following/artists_and_labels
Ты просто глянь на списочек жанров, устанешь, а я всё это чекаю, покупаю, качаю, слежу.
Поясни за второй вопрос, вброшу что-нибудь
Да просто экономия места, музыки пиздец уже, в облако кидаю не часто прослушиваемые жанры. У меня интернет еще не особо то быстрый, выкачивать потом эти 24, я смысла в них особого не вижу, мне мастерингом не заниматься, бутлегов писать не планирую. А если нужно побаловаться, то всегда можно достать их из первоисточника, в данном случае Bandcamp.
https://bandcamp.com/fossf1/following/genres
https://bandcamp.com/fossf1/following/artists_and_labels
Ты просто глянь на списочек жанров, устанешь, а я всё это чекаю, покупаю, качаю, слежу.
Поясни за второй вопрос, вброшу что-нибудь
>>766567
А по второму вопросу - я забыл, что за aiff, в чем его особенности. Ну если идентичной битности, то какие могут быть потери? Наверное никаких
А по второму вопросу - я забыл, что за aiff, в чем его особенности. Ну если идентичной битности, то какие могут быть потери? Наверное никаких
>>766593
И дитхеринг наверное нинужен
И дитхеринг наверное нинужен
>>766565
Это не частичное сохраненение деталей. Это имитация деталей артефактами сжатия.
Не скажу, что это плохо, кстати.
>частичного сохранения деталей
Это не частичное сохраненение деталей. Это имитация деталей артефактами сжатия.
Не скажу, что это плохо, кстати.
2,3 Мб, 905x905>>766593
Да это тот же PCM, только эппловский. Блин, раздражает немного что не все кодировщики его поддерживают и в таком случае сначала aif/aiff в wav жать приходится.
Так уж и быть, раздаю бесплатные подарки. Спасибо за инфу. https://www60.zippyshare.com/v/IHyIka4F/file.html
Да это тот же PCM, только эппловский. Блин, раздражает немного что не все кодировщики его поддерживают и в таком случае сначала aif/aiff в wav жать приходится.
Так уж и быть, раздаю бесплатные подарки. Спасибо за инфу. https://www60.zippyshare.com/v/IHyIka4F/file.html
>>766649
ALAC жи есть, я как раз его юзаю, чтобы на афоню скинуть лосслесс музон в Apple Music. Эпловский аналог FLAC. Конвертирую в него из FLAC.
> Да это тот же PCM, только эппловский
ALAC жи есть, я как раз его юзаю, чтобы на афоню скинуть лосслесс музон в Apple Music. Эпловский аналог FLAC. Конвертирую в него из FLAC.
>>766652
Да я в данном случае предпочитаю Wavpack, в нем есть неоспоримая фича когда нужна экономия места. Гибридный режим позволяет держать сразу lossless и lossy размером как любой другой lossless контейнер. То бишь возьмем твой трек ALAC, предположим размером 25мб и Wavpack тем же 25мб, в которые ужались сразу lossy и lossless и их общий размер составляет тот же 25мб. А в случае ALAC получится что к этим 25мб нужно еще прибавить ~10 для хранения lossy AAC, получится уже ~35. Я знаю что на FLAC тоже есть такое, но сторонними васянами написано и не уверен будет ли работать везде, уже жаловался народ на траблы. А в Wavpack это из коробки.
>>766655
Что-то с кодировкой не то, перекодируй документ, если нужно, да там ничего важного не написано, просто комментарии для упрощения. Но хоть официально бесплатное и в любом формате.
Да я в данном случае предпочитаю Wavpack, в нем есть неоспоримая фича когда нужна экономия места. Гибридный режим позволяет держать сразу lossless и lossy размером как любой другой lossless контейнер. То бишь возьмем твой трек ALAC, предположим размером 25мб и Wavpack тем же 25мб, в которые ужались сразу lossy и lossless и их общий размер составляет тот же 25мб. А в случае ALAC получится что к этим 25мб нужно еще прибавить ~10 для хранения lossy AAC, получится уже ~35. Я знаю что на FLAC тоже есть такое, но сторонними васянами написано и не уверен будет ли работать везде, уже жаловался народ на траблы. А в Wavpack это из коробки.
>>766655
Что-то с кодировкой не то, перекодируй документ, если нужно, да там ничего важного не написано, просто комментарии для упрощения. Но хоть официально бесплатное и в любом формате.
Как научиться пользоваться архиваторами?
вот например есть файлы, которые когда-нибудь (возможно) понадобятся, но большую часть времени они только валяются на диске. Как их лучше всего упаковывать и сжимать?
Попробовал случайным образом потыкать пресеты 7-Zip, но ничего путного не получилось, а в некоторых случаях архив даже начал больше весить, чем исходные файлы.
Каким образом добиваются уменьшение размера в два раза и выше? Например как в репаках игр или здесь: https://rutracker.org/forum/viewtopic.php?t=5489805
вот например есть файлы, которые когда-нибудь (возможно) понадобятся, но большую часть времени они только валяются на диске. Как их лучше всего упаковывать и сжимать?
Попробовал случайным образом потыкать пресеты 7-Zip, но ничего путного не получилось, а в некоторых случаях архив даже начал больше весить, чем исходные файлы.
Каким образом добиваются уменьшение размера в два раза и выше? Например как в репаках игр или здесь: https://rutracker.org/forum/viewtopic.php?t=5489805
>>767650
Создаешь профиль по умолчанию в винрар с форматом архива Rar с максимальным сжатием, и если по одному не будешь файлы вытаскивать, то непрерывный архив
Создаешь профиль по умолчанию в винрар с форматом архива Rar с максимальным сжатием, и если по одному не будешь файлы вытаскивать, то непрерывный архив
>>686610 (OP)
Православная это шебм4ретардс, ебаный пикабушник.
Православная это шебм4ретардс, ебаный пикабушник.
>>767728
совсем дебич? Пошел обратно на свой пикабу и больше не возращайся.
>FFmpeg
>пикабушник
>Православная это GUI для FFmpeg
совсем дебич? Пошел обратно на свой пикабу и больше не возращайся.
136 Кб, 1430x715Есть 17гб фото в пнг. Чем можно существенно сжать без потери (или с минимальной потерей) в качестве?
Каво
>>687799
Взгляни на небо, посмотри, там плывут облака
Взгляни на небо, посмотри, там плывут облака
>>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"
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"
19 Кб, 846x272>>777882
>>777961
>>777999
>>777887
Потестил.
Везде максимальное сжатие без потерь, кроме heic. В нем есть минимальные отклонения. Был бы вином, если бы не зеленил картинку, и нет нормальных приложений для просмотра.
JPC - LuraWave JPEG-2000 Format, без потерь и быстро, но мертвый.
AVIF - oche dolgo, даже в webp будет все конвертироваться ~30 часов.
>>777961
>>777999
>>777887
Потестил.
Везде максимальное сжатие без потерь, кроме heic. В нем есть минимальные отклонения. Был бы вином, если бы не зеленил картинку, и нет нормальных приложений для просмотра.
JPC - LuraWave JPEG-2000 Format, без потерь и быстро, но мертвый.
AVIF - oche dolgo, даже в webp будет все конвертироваться ~30 часов.
>>778105
Тут только нужно смотреть как конвертируется в AVIF и HEIC, скорее всего в yuv444/yuv422 (а это уже потери, как при цветовом преобразовании, так и сохраняется меньше самих цветов).
В AVIF настоящий lossless режим есть через https://github.com/AOMediaCodec/libavif
Avifenc --lossless
Для HEIC были какие то форки с RGB, но надо разбираться и размеры там будут существенно выше.
У Webp если недостаточно скорости, можно использовать настройки побыстрее, даже на них результаты вполне себе.
Тут только нужно смотреть как конвертируется в AVIF и HEIC, скорее всего в yuv444/yuv422 (а это уже потери, как при цветовом преобразовании, так и сохраняется меньше самих цветов).
В AVIF настоящий lossless режим есть через https://github.com/AOMediaCodec/libavif
Avifenc --lossless
Для HEIC были какие то форки с RGB, но надо разбираться и размеры там будут существенно выше.
У Webp если недостаточно скорости, можно использовать настройки побыстрее, даже на них результаты вполне себе.
>>778105
Можно еще посмотреть тесты, которые я кидал в другом треде https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/
Также там есть тест PNG оптимизаторов (в табе PNG), в Jpeg XL сжимать на максимальных настройках тоже будет очень медленно, да и сам формат пока еще развивается, вроде как уже стандартизировали, но есть вероятность что новые версии не распакуют старые пикчи, тут уж на свой риск.
Можно еще посмотреть тесты, которые я кидал в другом треде https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/
Также там есть тест PNG оптимизаторов (в табе PNG), в Jpeg XL сжимать на максимальных настройках тоже будет очень медленно, да и сам формат пока еще развивается, вроде как уже стандартизировали, но есть вероятность что новые версии не распакуют старые пикчи, тут уж на свой риск.
>>778294
Он также в них сохраняет дополнительные данные для обратного преобразования без потерь в RGB, можно почитать объяснение автора на реддите:
https://www.reddit.com/r/AV1/comments/gdi12d/libavif_v073_tagged_including_native_lossless_mode/fplg9s0/
Он также в них сохраняет дополнительные данные для обратного преобразования без потерь в RGB, можно почитать объяснение автора на реддите:
https://www.reddit.com/r/AV1/comments/gdi12d/libavif_v073_tagged_including_native_lossless_mode/fplg9s0/
Как максимально жать в лосслесс авиф? Пробовал "avifenc -l -s 0 image.png image.avif" с этой пикчей >>687799, но результат весит больше, чем лосслесс вебп.
>>778567
xnconvert
xnconvert
>>778480
Что у тебя за калькулятор?
Что у тебя за калькулятор?
>>778567
Так и жать, если нужен настоящий Lossless, все остальные утилиты жмут в yuv444 не сохраняя дополнительные данные с RGB (можно точно также как они сжимать и avifenc, указав нулевой квантайзер --min 0, но не добавляя lossless). AVIF вообще не особо предназначен для конвертации чего то с RGB в lossless, т.к. у него все это сделано через костыли и очень сильно страдает сжатие.
Некоторые цитаты:
(jdrago)
(jonsneyers)
Так и жать, если нужен настоящий 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)
>>763470
Кек, а в ноклу 808 из доисторического 2012 можно хоть 2 терабайта карточку засунуть как родную, которых до сих пор не выпустили.
только скорость будет 10 мегов/с
Кек, а в ноклу 808 из доисторического 2012 можно хоть 2 терабайта карточку засунуть как родную, которых до сих пор не выпустили.
только скорость будет 10 мегов/с
Как одной строчкой команд, а не кучей заходов в 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 в нижнем правом углу и засунуть его в финальный шебм. И всё это сразу одной строкой в консолечке. Чот получится наверно пердолинг не хуже установки генту.
нихуя не понимаю, нахуя рекомендовать heic / avif?
Была папка 7гб, и bmp, и jpg, и png, разные размеры, разное качество, с прозрачностями и без, анимации и без.
Прогнал за 5+ минут с помощью xnview в webp, в результате и проводник читает формат, и папочка сжалась до 1.4гб, и в программах фоточки видны.
Попробовал перегнать сначала те же 7гб в avif / heic (результаты одинаковы), 4% (я хз сколько это мб, может мб 300-350), около часа.
Впизду я ебал такой пиздец. Вы ебанутые.
Ради теста взял AVIF / HEIC / WEBP посмотрел на то, что получилось, и время затраченное.
всё кроме webp не выдерживает никакой блядь критики.
Как по поддержке банально софтом, так и по времени обработки, конвертации, сжатия, и так далее.
Вопрос - нахуя он нужен?
Была папка 7гб, и bmp, и jpg, и png, разные размеры, разное качество, с прозрачностями и без, анимации и без.
Прогнал за 5+ минут с помощью xnview в webp, в результате и проводник читает формат, и папочка сжалась до 1.4гб, и в программах фоточки видны.
Попробовал перегнать сначала те же 7гб в avif / heic (результаты одинаковы), 4% (я хз сколько это мб, может мб 300-350), около часа.
Впизду я ебал такой пиздец. Вы ебанутые.
Ради теста взял AVIF / HEIC / WEBP посмотрел на то, что получилось, и время затраченное.
всё кроме webp не выдерживает никакой блядь критики.
Как по поддержке банально софтом, так и по времени обработки, конвертации, сжатия, и так далее.
Вопрос - нахуя он нужен?
Какой видеокодек жмёт круче всех, чтоб весило хуйню, а качество было неотличимо от оригинала?
Прошу прощёния если уже было.
Хватаем первую попавшуюся в папке гифку (пнг и джипег пока не вкостылены) и приклеиваем звук.
Хватаем первую попавшуюся в папке гифку (пнг и джипег пока не вкостылены) и приклеиваем звук.
>>778912
x264
x264
>>778978
Отступы там - самый из незначительных грехов. Он нигде не определяет рабочую папку, потому если запустить скрипт типа ~/scripts/myyobaffmpegwrapper/yoba.sh, то они пидорнёт случайный трек и картинку с хомяка.
Отступы там - самый из незначительных грехов. Он нигде не определяет рабочую папку, потому если запустить скрипт типа ~/scripts/myyobaffmpegwrapper/yoba.sh, то они пидорнёт случайный трек и картинку с хомяка.
264 Кб, mp4,854x480, 0:08
>>778985
Спасибо за замечания
Спасибо за замечания
>>778945
Лучше сначала просто перегнать гифку в видео, а после объединить с музычкой:
ffmpeg -i audio.mp3 -stream_loop -1 -i video.webm -c:a libopus -b:a 64k -c:v copy -shortest output.webm
Лучше сначала просто перегнать гифку в видео, а после объединить с музычкой:
ffmpeg -i audio.mp3 -stream_loop -1 -i video.webm -c:a libopus -b:a 64k -c:v copy -shortest output.webm
>>779308
Стоит так же заметить, что при таком способе размер файла будет больше.
Стоит так же заметить, что при таком способе размер файла будет больше.
>>779346
А если надо файл гигов так на 24 перекодировать?
А если надо файл гигов так на 24 перекодировать?
>>778996
С vp9 почему-то добавляется тишина в конец.
С vp9 почему-то добавляется тишина в конец.
>>686673
Открытый же
Открытый же
>>778913
Не, у меня не 9900k конечно же.
Но i5, довольно производительный.
Поэтому я хз, это нихуя не норма.
>9900k
Не, у меня не 9900k конечно же.
Но i5, довольно производительный.
Поэтому я хз, это нихуя не норма.
Записываю окно с ffmpeg -f framerate 60 -i -title "window_name" -c:v h264_nvenc -qp 0 output.mkv. Курсор двигается, но окно заморожено. Если с такими же параметрами записывать весь экран, то все норм. Чяднт?
>>780093
браузером
браузером
>>780093
Gwenview
Gwenview
>>780093
HoneyView
HoneyView
3,1 Мб, 2560x1920>>778865
>>779871
Лол, ты чем жал? Я через ffmpeg + паковщик (gac) минимум по 10% получал, даже с суперужатых пикч с вк. Если ты не в состоянии понять как оно работает, это не значит, что оно не работает.
Не завезли ещё поддержку, гружу сюда.
https://files.catbox.moe/znx8on.heic
Вот у меня мужик с котом есть. 3 метра превратились в 560кб, разницы я не вижу inb4: слепой.
Кодировалось это всё на slow 4 секунды. На placebo 15.
Делюсь скриптом для красноглазых:
https://pastebin.com/9pwb2kNb
А avif говно, тут согласен. Полчаса одну картинку обрабатывает.
>>779871
> HEIC
Лол, ты чем жал? Я через ffmpeg + паковщик (gac) минимум по 10% получал, даже с суперужатых пикч с вк. Если ты не в состоянии понять как оно работает, это не значит, что оно не работает.
Не завезли ещё поддержку, гружу сюда.
https://files.catbox.moe/znx8on.heic
Вот у меня мужик с котом есть. 3 метра превратились в 560кб, разницы я не вижу inb4: слепой.
Кодировалось это всё на slow 4 секунды. На placebo 15.
Делюсь скриптом для красноглазых:
https://pastebin.com/9pwb2kNb
А avif говно, тут согласен. Полчаса одну картинку обрабатывает.
Котаны, возможен ли в принципе горизонтальный флип (т.е. зеркальное отображение) видео без пережатия? Ну или как и чем это сделать с минимальными потерями?
>>780419
Метадатой дописать hflip, например?
https://it-handbook.ru/windows/povorot-mp4-video-s-pomoshhyu-ffmpeg.html
Метадатой дописать hflip, например?
https://it-handbook.ru/windows/povorot-mp4-video-s-pomoshhyu-ffmpeg.html
>>780444
А, сорь, только сейчас посмотрел что не то кинул.
Вот тут чувак флипает метадатой и судя по всему мало какие плееры проигрываю его хотелки: https://superuser.com/questions/1393880/edit-mp4-hex-data-to-vertically-or-horizontally-flip-video-in-a-lossless-manner
А, сорь, только сейчас посмотрел что не то кинул.
Вот тут чувак флипает метадатой и судя по всему мало какие плееры проигрываю его хотелки: https://superuser.com/questions/1393880/edit-mp4-hex-data-to-vertically-or-horizontally-flip-video-in-a-lossless-manner
>>780488
crypt of the necrodancer
crypt of the necrodancer
>>780365
Только такая конвертация не имеет смысла, выигрывается мало, а потери при повторном будут всегда, даже в такой же или чуть больший размер
Разницу видно, в основном сожрало все детали, но это ладно, бывает что нужна просто фотка поменьше без сильных артефактов
Но если такие потери устраивают, вот для примера WebP даже чуть меньшего размера чем этот HEIC https://files.catbox.moe/uukfg3.webp
(с ним тоже скорей всего разницы не будет видно, а учитывая что у HEIC никогда не будет поддержки в популярных браузерах из-за своих жестких патентов, то смысл все в него все переводить)
>минимум по 10% получал, даже с суперужатых пикч с вк
Только такая конвертация не имеет смысла, выигрывается мало, а потери при повторном будут всегда, даже в такой же или чуть больший размер
>Вот у меня мужик с котом есть. 3 метра превратились в 560кб, разницы я не вижу
Разницу видно, в основном сожрало все детали, но это ладно, бывает что нужна просто фотка поменьше без сильных артефактов
Но если такие потери устраивают, вот для примера WebP даже чуть меньшего размера чем этот HEIC https://files.catbox.moe/uukfg3.webp
(с ним тоже скорей всего разницы не будет видно, а учитывая что у HEIC никогда не будет поддержки в популярных браузерах из-за своих жестких патентов, то смысл все в него все переводить)
Жму аудиокниги и подкасты в opus VBR 56 (ниже уже явное говно и если в книге есть музычка, то лают шакалы). Жал лёгкий тихий джаз для прикола в CBR 64 - охуел от того, что на слух сложно отличить от исходника. Более насыщенная и громкая музыка типа митола естественно рассыпается в говно даже на 128. Всю коллекцию музла из mp3 320 и флака перегнал в ogg vorbis 192, остался доволен.
Всё правильно делаю?
Теперь ищу способ уменьшить размер коллекции манги, в основном ЧБ, смесь жпг и пнг. Что посоветуете? Пытался найти баланс в жпг, на 75 шакалы вроде не так ужасны, но выигрыш по качеству маленький.
Всё правильно делаю?
Теперь ищу способ уменьшить размер коллекции манги, в основном ЧБ, смесь жпг и пнг. Что посоветуете? Пытался найти баланс в жпг, на 75 шакалы вроде не так ужасны, но выигрыш по качеству маленький.
>>780855
Ну как сказать. Я согласен, что 192 опуса с ютуба находиться на одном уроне с 320 мр3, но пережимать лосси в лосии - такая себе затея. Потери накапливаются.
Твоё право, если ты разницы не слышишь. Главное это своё говно пережатое потом среди других не распространяй.
Начни с webp. Незначительно проигрывает heif, зато быстр и поддерживается уже практически всеми тостерами.
> начал с опуса, закончил ворбисом
> пережал из лосси mp3 в лосси ворбис
> Всё правильно делаю?
Ну как сказать. Я согласен, что 192 опуса с ютуба находиться на одном уроне с 320 мр3, но пережимать лосси в лосии - такая себе затея. Потери накапливаются.
Твоё право, если ты разницы не слышишь. Главное это своё говно пережатое потом среди других не распространяй.
> Теперь ищу способ уменьшить размер коллекции манги, в основном ЧБ, смесь жпг и пнг.
Начни с webp. Незначительно проигрывает heif, зато быстр и поддерживается уже практически всеми тостерами.
>>780855
Алсо если реально ЧБ а не оттенки серого, то можно много выиграть путём принудительной индексации и пнг-оптимизации. Но тут смотреть реальные примеры надо.
Алсо если реально ЧБ а не оттенки серого, то можно много выиграть путём принудительной индексации и пнг-оптимизации. Но тут смотреть реальные примеры надо.
>>780869
320 мп3 это очень хорошее качество, которое от лосслеса хуй кто отличит в принципе. Ну может пара миллионов уникумов на всей планете с феноменальным слухом что-то будут подозревать. Пережимал чтобы место освободить (сотни гигов).
В курсе.
Либо не слышу, либо отказываюсь верить, что есть какая-то разница. Музыкант+звукач, зарабатываю этим деньги, со слухом всё ок, всё ещё могу слышать 19500Гц, хотя уже бородат.
Не понял этого. Зачем я буду свою личную коллекцию музла где-то распространять?
Попробую.
XnConvert почему-то ошибку выдаёт, "файл не является изображением". Через что ещё попробовать?
>>780875
Попробую, спасибо.
>>780876
Слишком толсто. Сосите хуй, пожалуйста.
>пережал из лосси mp3 в лосси ворбис
320 мп3 это очень хорошее качество, которое от лосслеса хуй кто отличит в принципе. Ну может пара миллионов уникумов на всей планете с феноменальным слухом что-то будут подозревать. Пережимал чтобы место освободить (сотни гигов).
>такая себе затея. Потери накапливаются.
В курсе.
>Твоё право, если ты разницы не слышишь.
Либо не слышу, либо отказываюсь верить, что есть какая-то разница. Музыкант+звукач, зарабатываю этим деньги, со слухом всё ок, всё ещё могу слышать 19500Гц, хотя уже бородат.
> Главное это своё говно пережатое потом среди других не распространяй.
Не понял этого. Зачем я буду свою личную коллекцию музла где-то распространять?
>Начни с webp
Попробую.
>heif
XnConvert почему-то ошибку выдаёт, "файл не является изображением". Через что ещё попробовать?
>>780875
Попробую, спасибо.
>>780876
Слишком толсто. Сосите хуй, пожалуйста.
>>780855
Если не так срочно нужна поддержка везде, то можно подождать Jpeg XL, у него очень хорошее lossless сжатие (для перегона пикч с PNG, иногда чуть хуже FLIF, но вот только FLIF существенно медленней, на декодирование даже в десятки раз и он заброшен) и плюс к этому можно уменьшить обычные Jpeg на 20-23% совсем без потерь (пример в онлайне https://google.github.io/brunsli/), ну а с потерями и еще больше.
В другие форматы уже такое себе, ну разве что еще в WebP есть вариант PNG пережать без потерь (все остальное или плохо жмет в lossless или очень медленно), а вот Jpegи пусть лежат, они все таки обычно поменьше PNG весят, да и каждый раз дополнительные потери будут (выйдет еще какой то новый формат и опять захочется пережимать, еще больше все зашакаливая, ну или искать все эти исходники)
>Теперь ищу способ уменьшить размер коллекции манги, в основном ЧБ, смесь жпг и пнг. Что посоветуете?
Если не так срочно нужна поддержка везде, то можно подождать Jpeg XL, у него очень хорошее lossless сжатие (для перегона пикч с PNG, иногда чуть хуже FLIF, но вот только FLIF существенно медленней, на декодирование даже в десятки раз и он заброшен) и плюс к этому можно уменьшить обычные Jpeg на 20-23% совсем без потерь (пример в онлайне https://google.github.io/brunsli/), ну а с потерями и еще больше.
В другие форматы уже такое себе, ну разве что еще в WebP есть вариант PNG пережать без потерь (все остальное или плохо жмет в lossless или очень медленно), а вот Jpegи пусть лежат, они все таки обычно поменьше PNG весят, да и каждый раз дополнительные потери будут (выйдет еще какой то новый формат и опять захочется пережимать, еще больше все зашакаливая, ну или искать все эти исходники)
>>780869
Озадачил ты меня этой фразой, решил проверить. Взял исходник в wav, пережал в vorbis 192 и opus 128, чтобы их размеры были примерно одинаковые. Закинул все 3 в давку и начал сравнивать, пуская в противофазу, ну и хули, как и ожидал - vorbis срезает ультра-высокие как обычно, в противофазе слышно исключительно шипящие, а opus вырезает вообще по всему спектру по чуть-чуть и в противофазе с wav слышно разницу вплоть до суб-низов, но высокочастотное шипение и на vorbis и на opus примерно одинаковое. Вот хуй знает, что из этого лучше - чуть больший срез высоких у vorbis с сохранением всего остального или вырезание по всему спектру у opus.
>начал с опуса, закончил ворбисом
Озадачил ты меня этой фразой, решил проверить. Взял исходник в wav, пережал в vorbis 192 и opus 128, чтобы их размеры были примерно одинаковые. Закинул все 3 в давку и начал сравнивать, пуская в противофазу, ну и хули, как и ожидал - vorbis срезает ультра-высокие как обычно, в противофазе слышно исключительно шипящие, а opus вырезает вообще по всему спектру по чуть-чуть и в противофазе с wav слышно разницу вплоть до суб-низов, но высокочастотное шипение и на vorbis и на opus примерно одинаковое. Вот хуй знает, что из этого лучше - чуть больший срез высоких у vorbis с сохранением всего остального или вырезание по всему спектру у opus.
>>781371
Ну так. Огг - это всего лишь контейнер. А ворбис и опус - совершенно разные кодеки из разных эпох с разными задачами.
Опус, емпнип, добавляет смещение. Сдвигай фазу для минимизации диффа. Плюс апконвертит в 48000, потому лучше на родной частоте и сравнивать.
Ну и чисто моё мнение. Лучше когда акустическая модель вырезает инфу везде понемногу, чем тупой Lowpass "режьте всех кто выше 18к, господь разберётся где свои".
Ну так. Огг - это всего лишь контейнер. А ворбис и опус - совершенно разные кодеки из разных эпох с разными задачами.
Опус, емпнип, добавляет смещение. Сдвигай фазу для минимизации диффа. Плюс апконвертит в 48000, потому лучше на родной частоте и сравнивать.
Ну и чисто моё мнение. Лучше когда акустическая модель вырезает инфу везде понемногу, чем тупой Lowpass "режьте всех кто выше 18к, господь разберётся где свои".
>>781429
Ну вот поэтому я и пережал всю музыку в vorbis 192, а аудиокниги в opus 56 VBR, потому что opus реально круто себя ведёт на таких низких битрейтах и голос в книгах не превращается в глухое бульканье как с другими кодеками.
Вот про это не знал. Попробую.
Скорее вопрос вкуса, да и для разной музыки разный подход скорее нужен. Наверное если прогнать пару десятков очень разных жанров через спек, то обнаружится, что в половине из них информация выше 16-17КГц вообще отсутствует.
>с разными задачами
Ну вот поэтому я и пережал всю музыку в vorbis 192, а аудиокниги в opus 56 VBR, потому что opus реально круто себя ведёт на таких низких битрейтах и голос в книгах не превращается в глухое бульканье как с другими кодеками.
>Опус, емпнип, добавляет смещение. Сдвигай фазу для минимизации диффа.
Вот про это не знал. Попробую.
>Лучше когда акустическая модель вырезает инфу везде понемногу, чем тупой Lowpass
Скорее вопрос вкуса, да и для разной музыки разный подход скорее нужен. Наверное если прогнать пару десятков очень разных жанров через спек, то обнаружится, что в половине из них информация выше 16-17КГц вообще отсутствует.
Запарился, короче, вопросом перешакаливания жипега в хеиф. Нашкалил жипегов от q100 до q4, затем каждый пожал хейфом от 100 до 1 и поссчитал ssim по отношению к несжатому оригналу. Ну вот какие выводы просятся:
1) Хейф расшакалваиет пережатый жипег - подтверждено. Конечно только сильно пережатый с q<60 и на определённых настройках, и не больше чем на пару пунктов, но байки "хейф сделал файл лудше" теперь не такие байки.
2) Практически всегда можно не ссать и переживать до heif q80-60 , качество скорее всего останется неизменным, в худшем случае снизится до жипега уровня q95.
3) Нет нужды запариваться и искать первоисточник. Как бы исходник изначально не был пережат - его искажения предсказуемые: либо не хуже чем напортило в жипеге , либо потом перходят в кривую пережатя оригинала.
Пока только глаз, сейчас ещё фотки с другой энтропией попробую.
1) Хейф расшакалваиет пережатый жипег - подтверждено. Конечно только сильно пережатый с q<60 и на определённых настройках, и не больше чем на пару пунктов, но байки "хейф сделал файл лудше" теперь не такие байки.
2) Практически всегда можно не ссать и переживать до heif q80-60 , качество скорее всего останется неизменным, в худшем случае снизится до жипега уровня q95.
3) Нет нужды запариваться и искать первоисточник. Как бы исходник изначально не был пережат - его искажения предсказуемые: либо не хуже чем напортило в жипеге , либо потом перходят в кривую пережатя оригинала.
Пока только глаз, сейчас ещё фотки с другой энтропией попробую.
>>780365
Так нехуй выкручивать speed на ноль. Оставляй дефолтное значение, можно ещё jobs выставить по количеству потоков проца.
>А avif говно, тут согласен. Полчаса одну картинку обрабатывает.
Так нехуй выкручивать speed на ноль. Оставляй дефолтное значение, можно ещё jobs выставить по количеству потоков проца.
Обнаружил что у меня была старая версия опуса в гуй-мокропиське. Скачал последнюю, воткнул, заебись. Аудиокниги в 28 VBR охуительно кодируются. Если ниже, то Ш и С начинают люто шуметь, при этом на ультра-высоких добавляется какой-то рваный шум, будто биткрашер навесили.
Почему макак не запилит автоматическое пожатие картинок в ЖИПЕГ? С возможностью покрутить качество или вообще не пожимать, примерно как в дашчане. Заебали картинки в 15 метров.
>>803544
Проблемы замкадска москвича не ебут
Проблемы замкадска москвича не ебут
143 Кб, 1204x771>>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+ точно...
> Интересно обоснование этого тезиса.
Может быть бы ты загуглил?
https://minds.wisconsin.edu/bitstream/handle/1793/45041/ECE 790 Hsin-Yu Chen project Report.pdf?sequence=1&isAllowed=y
Но есть некоторые: НО.
То, что он описывает по поводу памяти и синхронизации между КПУ и ГПУ - я не могу сказать что и не актуально, и что актуально.
Т.е. изменения с момента публикации исследования в GPU были, да и производительность увеличилась раз так в 500+ плюс память так же быстрее стала, не говоря о чипах и так далее...
Но и процы тоже быстрее стали на самом деле, не в 500+ раз, но в раз 5+ точно...
>>756561
это петушиное кукрекание про прогресс
это петушиное кукрекание про прогресс
>>756561
Ты понимаешь, что "популярность", это быть одним из первых и лучших в чем-то и не сдаваться до конца. А не стек технологий...
это касается вообще всего о чем ты слышал:
nginx
winrar
kaspersky
norton
windows
debian
ubuntu
да любой популярный (очень популярный) софт возьми...
Тот же AIMP...
Я очень хорошо помню как он появился...
Он появился когда уже WinAMP всех заебал.
Аимп выглядел свежо, дохуя фич было, реально мощная альтернатива была всяким jetPlayer, Light Alloy, и так далее...
Тем более WinAMP... В ту же пору появился и deadbeaf кстати...
>Популярность и распространённость — вот что действительно важно
Ты понимаешь, что "популярность", это быть одним из первых и лучших в чем-то и не сдаваться до конца. А не стек технологий...
это касается вообще всего о чем ты слышал:
nginx
winrar
kaspersky
norton
windows
debian
ubuntu
да любой популярный (очень популярный) софт возьми...
Тот же AIMP...
Я очень хорошо помню как он появился...
Он появился когда уже WinAMP всех заебал.
Аимп выглядел свежо, дохуя фич было, реально мощная альтернатива была всяким jetPlayer, Light Alloy, и так далее...
Тем более WinAMP... В ту же пору появился и deadbeaf кстати...
>>756561
Даунич? Опус в ютубе и спотифае.
Даунич? Опус в ютубе и спотифае.
21 Кб, 568x659>>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 изначально), при том же качестве визуально видео и аудио.
решил пожать 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 изначально), при том же качестве визуально видео и аудио.
21 Кб, 568x659>>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 изначально), при том же качестве визуально видео и аудио.
решил пожать 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 изначально), при том же качестве визуально видео и аудио.
Аноны, есть ли в ffmpeg возможность сделать максимально компактный видеоролик по схеме?
1. Вступление ролик1
2. Цикл ролик2
3. Окончание ролик3
Видел, что зацикливали анимации без увеличения объема, а такое можно?
1. Вступление ролик1
2. Цикл ролик2
3. Окончание ролик3
Видел, что зацикливали анимации без увеличения объема, а такое можно?
241 Кб, 469x249>>688040
фапБ ебучее мыло
фапБ ебучее мыло
>>804538
Понятно. Только этот поток не занимает пространство, т.к. один фрагмент повторяется на протяжении всего ролика. Я на 100% уверен, что кодек позволяет нелинейно ссылаться на кадры и можно собрать ролик из циклических фрагментов, которые будут занимать только свой кусок пространства, а не копироваться на весь клип.
Только как это сделать я не знаю, вот и спросил.
Понятно. Только этот поток не занимает пространство, т.к. один фрагмент повторяется на протяжении всего ролика. Я на 100% уверен, что кодек позволяет нелинейно ссылаться на кадры и можно собрать ролик из циклических фрагментов, которые будут занимать только свой кусок пространства, а не копироваться на весь клип.
Только как это сделать я не знаю, вот и спросил.
>>804186
Который настолько охуенен, что целиком распидорашивается от малейшей битовой ошибки.
>при наличии охуенного и открытого 7z
Который настолько охуенен, что целиком распидорашивается от малейшей битовой ошибки.
>>805017
Так-то да, 7z не умеет, но для подавляющего количества задач это не требуется.
А ты сам где это реально применяешь?
> малейшей битовой ошибки.
Так-то да, 7z не умеет, но для подавляющего количества задач это не требуется.
А ты сам где это реально применяешь?
>>805300
Из-за этой хуйни перестал бэкапы жать в 7z. Потому что бэкапы на каком только говне не хранятся.
Из-за этой хуйни перестал бэкапы жать в 7z. Потому что бэкапы на каком только говне не хранятся.
Погонял avif на манге, заебись жмёт. Правда времени дохуя уходит и оперативку забивает моментально, но это не главное. Проблема остаётся в невозможности правильного определения степени сжатия для разного содержания.
По шкале квантизации от 0 до 63:
Цветные картинки жмёт заебись в пределах 10-20 с сохранением отличного качества при размере в 2-4 раза ниже чем жипег.
Если жать чб/серую мангу с этими настройками, жмёт так же в 2-4 раза.
Но если на чб/серых поставить 50-55, жмёт просто охуительно, почти в 10 раз, при этом визуально почти ничего не меняется.
Но если на 50-55 жать цветные, то шакалы просто пиздец.
И как мне, блять, сделать так, что бы из 250гб манги пожать отдельно цветные на одних настройках и чб отдельно на других настройках, при этом не вытаскивая пикчи руками из соответствующих папок, чтобы всё оставалось на своих местах?
По шкале квантизации от 0 до 63:
Цветные картинки жмёт заебись в пределах 10-20 с сохранением отличного качества при размере в 2-4 раза ниже чем жипег.
Если жать чб/серую мангу с этими настройками, жмёт так же в 2-4 раза.
Но если на чб/серых поставить 50-55, жмёт просто охуительно, почти в 10 раз, при этом визуально почти ничего не меняется.
Но если на 50-55 жать цветные, то шакалы просто пиздец.
И как мне, блять, сделать так, что бы из 250гб манги пожать отдельно цветные на одних настройках и чб отдельно на других настройках, при этом не вытаскивая пикчи руками из соответствующих папок, чтобы всё оставалось на своих местах?
>>808584
Надо ещё и размер пикчи учитывать.
>Проблема остаётся в невозможности правильного определения степени сжатия для разного содержания.
Надо ещё и размер пикчи учитывать.
52 Кб, 871x258>>808584
Нашкрептах за пять менут. Имаджмагик может посчитать тебе гистограмму, если на ней буду цвета отличные от серого то картинка цветная. Ну и разрешение так же.
Нашкрептах за пять менут. Имаджмагик может посчитать тебе гистограмму, если на ней буду цвета отличные от серого то картинка цветная. Ну и разрешение так же.
143 Кб, 664x794Господа шакалы, посоветуйте, в какой lossy кодек лучше жать музыку - aac-lc или opus? А может что-то другое? Нужна хорошая поддержка тегов в Windows 10 и Android 7.0+ и поддержка софтом и хардом. Кроме того, интересно, насколько сильно накапливаются искажения при пережатии из mp3 320k?
>>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 баксов, там уже третья версия вышла.
Из 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 баксов, там уже третья версия вышла.
>>811952
Потестировал, шиндовс 10 из коробки до сих пор не умеет в теги vorbis (хотя полная поддержка opus добавлена год назад), на андроиде с этим тоже есть некоторые проблемы (везде решается установкой стороннего плеера). Наверное, всё же буду жать в AAC, с ним нигде нет проблем, а на качество на низком битрейте мне всё равно, т. к. музыку жму в 256k vbr (мне не нужно максимальное сжатие, просто что-то лучше древнего mp3 и его чехарды с тегами).
Потестировал, шиндовс 10 из коробки до сих пор не умеет в теги vorbis (хотя полная поддержка opus добавлена год назад), на андроиде с этим тоже есть некоторые проблемы (везде решается установкой стороннего плеера). Наверное, всё же буду жать в AAC, с ним нигде нет проблем, а на качество на низком битрейте мне всё равно, т. к. музыку жму в 256k vbr (мне не нужно максимальное сжатие, просто что-то лучше древнего mp3 и его чехарды с тегами).
35 Кб, 498x445Не тонем
>>817218
нет смысла никакого.
Мимо, анон который пережал огромный архив музла в разные форматы, а теперь страдает от этого. Потому что нигде, кроме плеера эти форматы и нахуй не нужны.
Тоже касается и фото.
Хранить что-то в современных форматах можно лишь для АРХИВАЦИИ, но не как файлы, которыми изредка, да пользуешься, тем более если пользуешься регулярно. Ебли дохуища.
нет смысла никакого.
Мимо, анон который пережал огромный архив музла в разные форматы, а теперь страдает от этого. Потому что нигде, кроме плеера эти форматы и нахуй не нужны.
Тоже касается и фото.
Хранить что-то в современных форматах можно лишь для АРХИВАЦИИ, но не как файлы, которыми изредка, да пользуешься, тем более если пользуешься регулярно. Ебли дохуища.
>>817281
у плееров память не резиновая, ты как бы сам должен это знать, раз юзаеш. У телефонов и смартфонов как бы тоже. но те хотя-бы aac поддерживают (кроме артефактов древности), а смартфоны на android ещё и в opus могут.
>лишь для АРХИВАЦИИ
>кроме плеера эти форматы и нахуй не нужны
у плееров память не резиновая, ты как бы сам должен это знать, раз юзаеш. У телефонов и смартфонов как бы тоже. но те хотя-бы aac поддерживают (кроме артефактов древности), а смартфоны на android ещё и в opus могут.
>>817218
Для этого исходник нужен, а не этой чушью заниматься, из одного lossy в другой. Даже неизвестно какими способами всё это доставалось, в каком виде это было, с каким софтом, на каких сэмплах писано. Сервисы не особо то брезгуют и за исходник считают и lossy, которые потом же пережимают, набив еще больше искажений. это же касается и людей, кто рипует. Впрочем, что тут говорить, ты и сам это предлагаешь, а потом такие же это выкладывают, с друг другом делятся. Получается нескончаемый круговорот с последующим даунгрейдом. Представь что у тебя одна из этих вариаций, теперь ты предлагаешь из "этого" снова что-то ужимать. Самое банальное и частое: 320 лейбл -> 256aac айтюнс -> V0/V2 бесплатное, а теперь это у тебя и ты со своим
лол. разочарую вас, наверное, но такой клоунады 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 умеет).
Для этого исходник нужен, а не этой чушью заниматься, из одного 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 умеет).
>>817218
Для этого исходник нужен, а не этой чушью заниматься, из одного lossy в другой. Даже неизвестно какими способами всё это доставалось, в каком виде это было, с каким софтом, на каких сэмплах писано. Сервисы не особо то брезгуют и за исходник считают и lossy, которые потом же пережимают, набив еще больше искажений. это же касается и людей, кто рипует. Впрочем, что тут говорить, ты и сам это предлагаешь, а потом такие же это выкладывают, с друг другом делятся. Получается нескончаемый круговорот с последующим даунгрейдом. Представь что у тебя одна из этих вариаций, теперь ты предлагаешь из "этого" снова что-то ужимать. Самое банальное и частое: 320 лейбл -> 256aac айтюнс -> V0/V2 бесплатное, а теперь это у тебя и ты со своим
лол. разочарую вас, наверное, но такой клоунады 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 умеет).
Для этого исходник нужен, а не этой чушью заниматься, из одного 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 умеет).
>>817644
>>817752
вы не понимаете нихуя.
Пишу ещё раз. Смысл имеет только архивация для хранения, либо максимум для воспроизведения, не более (и то, с проблемами).
Я пережал огромную библиотеку медиа-файлов которые я слушаю\смотрю\читаю\просматриваю.
Потом по работе понадобилось запилить клипчики на ютуб, фш, AF, и так далее - и тут я сел на жопу. Потому что даже современное лицензионное ПО не поддерживает эти всякие ваши форматы. Причем проблема не только в этом, ещё хуже в том, что софт который нужен для работы - часто вообще не поддерживает ничего кроме: jpg, mp4, gif, png, bmp, mp3, wav.
Всё остальное - впизду, нахуй блядь.
>>817752
вы не понимаете нихуя.
Пишу ещё раз. Смысл имеет только архивация для хранения, либо максимум для воспроизведения, не более (и то, с проблемами).
Я пережал огромную библиотеку медиа-файлов которые я слушаю\смотрю\читаю\просматриваю.
Потом по работе понадобилось запилить клипчики на ютуб, фш, AF, и так далее - и тут я сел на жопу. Потому что даже современное лицензионное ПО не поддерживает эти всякие ваши форматы. Причем проблема не только в этом, ещё хуже в том, что софт который нужен для работы - часто вообще не поддерживает ничего кроме: jpg, mp4, gif, png, bmp, mp3, wav.
Всё остальное - впизду, нахуй блядь.
>>818559
Сам ты нипанимаеш. Ты сел на жопу не потому что форматы плохие, и даже не из-за кривого ентерпрайзного софта, а потому что ты lossless исходники удалил без бекапа. Страдай теперь, сам виноват.
>Потом по работе понадобилось запилить клипчики на ютуб, фш, AF, и так далее - и тут я сел на жопу
Сам ты нипанимаеш. Ты сел на жопу не потому что форматы плохие, и даже не из-за кривого ентерпрайзного софта, а потому что ты lossless исходники удалил без бекапа. Страдай теперь, сам виноват.
>>818559
Имплаинг что кто-то кроме 0.01% потенциальной аудитории на ютубе заметит разницу, если в клип воткнуть 3 раза пережатый звук. Лишние проблемы себе создаёшь на ровном месте.
Ну так пережми обратно в поддерживаемые форматы и отложи в сторонку, на время работы, а потом удали нахуй. В чём проблема-то? Или аудиофил дохуя?
Имплаинг что кто-то кроме 0.01% потенциальной аудитории на ютубе заметит разницу, если в клип воткнуть 3 раза пережатый звук. Лишние проблемы себе создаёшь на ровном месте.
>не поддерживает эти всякие ваши форматы. Причем проблема не только в этом, ещё хуже в том, что софт который нужен для работы - часто вообще не поддерживает ничего кроме: jpg, mp4, gif, png, bmp, mp3, wav.
Ну так пережми обратно в поддерживаемые форматы и отложи в сторонку, на время работы, а потом удали нахуй. В чём проблема-то? Или аудиофил дохуя?
ОДИННАДЦАТЬ ЧАСОВ
https://youtu.be/B-w03icSDFE?t=328
https://youtu.be/B-w03icSDFE?t=328
Ради интереса сравнил 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 и выше.
>>819469
Круто чё, теперь даже африканские дети смогут оценить отечественный кинематограф
Круто чё, теперь даже африканские дети смогут оценить отечественный кинематограф
>>819466
Ну да, всё правильно. В митоле очень высокая плотность высоких частот из-за гитар с дисторшеном и громких железок. Поэтому все лосси кодеки жиденько обсираются при недостаточном битрейте. Для себя нашёл минимум для митола и всякой сложной электроники - 96 VBR Opus и 160 VBR Vorbis. Ниже - на опусе начинается сужение стерео на высоких частотах (широкие тарелки, например, начинают звучать ближе к центру, теряется пространство), а на ворбисе ниже 160 начинают обрезаться ультра-высокие (можно заморочиться и посмотреть каждый битрей через spek).
Ну да, всё правильно. В митоле очень высокая плотность высоких частот из-за гитар с дисторшеном и громких железок. Поэтому все лосси кодеки жиденько обсираются при недостаточном битрейте. Для себя нашёл минимум для митола и всякой сложной электроники - 96 VBR Opus и 160 VBR Vorbis. Ниже - на опусе начинается сужение стерео на высоких частотах (широкие тарелки, например, начинают звучать ближе к центру, теряется пространство), а на ворбисе ниже 160 начинают обрезаться ультра-высокие (можно заморочиться и посмотреть каждый битрей через spek).
>>819252
Всю жизнь кинчики оставляли сжимать на ночь, тоже мне срок. Когда речь идёт о "сжал один раз" - "скачал миллион раз" то как вполне себе затраты окупаются.
Всю жизнь кинчики оставляли сжимать на ночь, тоже мне срок. Когда речь идёт о "сжал один раз" - "скачал миллион раз" то как вполне себе затраты окупаются.
>>819745
А вас не смущает перманентный апсэмпл из 44 в 48 в опусе? Это вообще хорошо для качества? Хочу определиться с форматом, но вызывает вопросы. mp3/aac отпадают.
А вас не смущает перманентный апсэмпл из 44 в 48 в опусе? Это вообще хорошо для качества? Хочу определиться с форматом, но вызывает вопросы. mp3/aac отпадают.
>>820795
Это похуй для качества. Не забивай голову аудиофильскими бреднями.
мимо-звукач
>Это вообще хорошо для качества?
Это похуй для качества. Не забивай голову аудиофильскими бреднями.
мимо-звукач
>>820805
Для lossy формата это похуй для качества. Ты от сжатия больше теряешь, чем от передискретизации.
Для lossy формата это похуй для качества. Ты от сжатия больше теряешь, чем от передискретизации.
не знаю, как я сюда попал но на всякий случай спрошу
как порезать АПЕ фубаром, если он дает файл целиком, без треков? сторонний софт не хочется ставить
как порезать АПЕ фубаром, если он дает файл целиком, без треков? сторонний софт не хочется ставить
>>820795
Сама передискретизации в большую сторону - операция без потерь, спасибо за это Котельникову.
Проблема в том что после передискретизации происходит повторное квантование. Но на фоне сжатия - это потери ультрамилипиздрические. Что-то уровня дроча на джиттер-коррекцию. Можешь не забивать голову.
Сама передискретизации в большую сторону - операция без потерь, спасибо за это Котельникову.
Проблема в том что после передискретизации происходит повторное квантование. Но на фоне сжатия - это потери ультрамилипиздрические. Что-то уровня дроча на джиттер-коррекцию. Можешь не забивать голову.
>>820977
cue файл есть?
cue файл есть?
>>820977
Cue файл вбрасывай в фубар, увидишь треки, выделяешь их и жмешь конвертацию в нужный тебе формат. Для поносного апе в фубар еще и плагин ставить нужно, да и сам апе лучше на "так" заменить - лучше и не столь требователен, быстрее сделает. А раз плеер не поддерживает, то надо выбирать кастомный режим, прописывать путь до mac.exe и вводить нужные ключи вручную, а их еще надо знать. Сам mac.exe еще и скачать нужно, а официально он только в виде инсталятора есть, что тоже ебанутость. Я не советую этот формат, никаких плюсов, пережми его в любой другой, какой нравится.
А можешь просто CUE Tools поставить, это гораздо проще к освоению и ничего уже не требует.
Cue файл вбрасывай в фубар, увидишь треки, выделяешь их и жмешь конвертацию в нужный тебе формат. Для поносного апе в фубар еще и плагин ставить нужно, да и сам апе лучше на "так" заменить - лучше и не столь требователен, быстрее сделает. А раз плеер не поддерживает, то надо выбирать кастомный режим, прописывать путь до mac.exe и вводить нужные ключи вручную, а их еще надо знать. Сам mac.exe еще и скачать нужно, а официально он только в виде инсталятора есть, что тоже ебанутость. Я не советую этот формат, никаких плюсов, пережми его в любой другой, какой нравится.
А можешь просто CUE Tools поставить, это гораздо проще к освоению и ничего уже не требует.
>>821293
aac ожидаемо соснул у opus и vorbis на 64kbps. Хотя для митала ни тот ни другой на таком низком битрейте не подходит, тарелки и гитары теряют ширину резко.
aac ожидаемо соснул у opus и vorbis на 64kbps. Хотя для митала ни тот ни другой на таком низком битрейте не подходит, тарелки и гитары теряют ширину резко.
>>821349
Надо заметить, что здесь используется профиль Low Complexity (LC), который не использует специальные фильтры для низких битрейтов.
Надо заметить, что здесь используется профиль Low Complexity (LC), который не использует специальные фильтры для низких битрейтов.
>>821485
Лет через 10, когда будет работать на любой микроволновке, ухх заживём!
Лет через 10, когда будет работать на любой микроволновке, ухх заживём!
>>686610 (OP)
Объясните чайнику, пожалуйста
Что лучше 264 или 265? Важно, впрочем, качество приближенное к оригинальналу.
Объясните чайнику, пожалуйста
Что лучше 264 или 265? Важно, впрочем, качество приближенное к оригинальналу.
>>821947
Просто только недавно об этом вообще услышал.
И пиздец статьи и статьи, столько инфы, а нахуй ничего не понятно
Просто только недавно об этом вообще услышал.
И пиздец статьи и статьи, столько инфы, а нахуй ничего не понятно
Обновить тред
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 15 августа 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 15 августа 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.