Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Представлен FLIF, новый формат сжатия изображений без потерь"	+/–
Сообщение от opennews (?), 02-Окт-15, 10:24
Развивается новый формат сжатия изображений FLIF (http://flif.info/) (Free Losless Image Format), опережающий по уровняю сжатия PNG и lossless-режимы форматов BPG (https://www.opennet.me/opennews/art.shtml?num=41198), JPEG2000 и WebP (https://www.opennet.me/opennews/art.shtml?num=36563). Исходные тексты утилит и библиотеки для работы с форматом FLIF доступны (https://github.com/jonsneyers/FLIF) под лицензией GPLv3. Заложенные в формат технологии распространяются на условиях безвозмездного использования и не требуют патентных отчислений. В основе FLIF лежит статистический алгоритм контекстно-адаптивного двоичного арифметического кодирования MANIAC (Meta-Adaptive Near-zero Integer Arithmetic Coding), который является одним из вариантов алгоритма CABAC (https://ru.wikipedia.org/wiki/CABAC) (Context-Adaptive Binary Arithmetic Coding), также используемого при кодировании видео H.264. Во FLIF  поддерживается прогрессивное чересстрочное кодирование (progressive interlacing), позволяющее отобразить эскиз изображение на основании части данных,  постепенно увеличивая качество по мере загрузки. Любой загруженный начальный блок сжатого файла может быть использован как закодированное с потерями изображение, сопоставимое (http://flif.info/example.php) по качеству с обычными форматами кодирования с потерями. Последующие данные уточняют модель и доводят её до представления полностью аналогичного исходному варианту. <center><iframe width="640" height="360" src="https://www.youtube.com/embed/ByH7RMsMxBY?rel=0" frameborder="0" allowfullscreen></iframe></center> По уровню сжатия FLIF, при тестировании на коллекции разнородных изображений (использовались тесты WebP (https://developers.google.com/speed/webp/docs/webp_lossless_... в среднем на 35% превосходит PNG (для оптимизированных PNG на 26%), на 37% JPEG 2000, на 15% WebP и на 22% BPG. Формат FLIF хорошо справляется с различными видами изображений, не требуя дополнительного тюнинга параметров кодирования. Например, для специфичных видов изображений (BPG и JPEG 2000 оптимальны для медицинских фотографии, PNG для штриховых рисунков, PNG и WebP для карт и т.п.) FLIF также опережает (https://docs.google.com/spreadsheets/d/16ghJEjf_T7TDTOg2Wlel... конкурентов в среднем на 10%. По скорости кодирования и декодирования текущая реализация FLIF пока отстаёт от других форматов. <center><a href="http://flif.info/comparison.png"><img src="https://www.opennet.me/opennews/pics_base/0_1443769211.png&q... style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center> Из возможностей FLIF можно отметить поддержку прозрачности, анимации, глубину цвета в 16 бит на канал, режим очень быстрого декодирования в пониженном разрешении.  В планах возможность интеграции метаданных (EXIF, профили ICC profiles, XMP), поддержка цветовых пространств (CMYK, YCbCr), режим сжатия с потерями, обеспечение поддержки в web-браузерах и оптимизация производительности. URL: https://github.com/jonsneyers/FLIF Новость: http://www.opennet.me/opennews/art.shtml?num=43074
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от пглгти (?), 02-Окт-15, 10:24	+8 +/–
Можно увеличить место на винте, пожав картинки.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #33

2. Сообщение от Аноним (-), 02-Окт-15, 10:34	–4 +/–
Больше, больше стандартов!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #34

3. Сообщение от freehck (ok), 02-Окт-15, 10:42	+/–
Очень неплохие результаты. Хотелось бы сравнение FLIF с BPG.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24, #137

4. Сообщение от Paver (ok), 02-Окт-15, 10:44	+6 +/–
... является одним из вариантов алгоритма КАБАК, хм, должно сработать!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13

5. Сообщение от Аноним (-), 02-Окт-15, 10:46	+/–
был еще недавно imagezero формат
Ответить | Правка | Наверх | Cообщить модератору

6. Сообщение от Нанобот (ok), 02-Окт-15, 10:48	+3 +/–
где ты видишь слово "стандарт" в тексте новости?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #31

7. Сообщение от Аноним (-), 02-Окт-15, 10:55	–1 +/–
"Алгоритм маньяк, являющийся одним из вариантов алгоритма кабак" А еще говорят, что у кодеров нет чувства юмора
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10

9. Сообщение от Аноним (-), 02-Окт-15, 10:56	+5 +/–
Проблема то актуальная. Популярная картинка может генерировать терабайты трафика. http://i.imgur.com/wU8sdky.png?1
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #20, #84

10. Сообщение от Аноним (-), 02-Окт-15, 11:00	+2 +/–
"Кодеры" имеют  к разработке таких алгоритмов отношение чуть менее чем 0. Это computer science, в России малоизвестное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #14

11. Сообщение от Аноним (-), 02-Окт-15, 11:06	–2 +/–
т.е. кодек жмет без потерь лучше чем jpeg с потерями?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29

12. Сообщение от Аноним (-), 02-Окт-15, 11:07	–4 +/–
Мне кажется, что уже пора вводить новый способ передачи мультимедийных данных от сервера к браузеру: если графический формат не поддерживается, то браузер запрашивает у сервера программу для декодирования.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #17, #19, #21, #35, #49

13. Сообщение от тоже Аноним (ok), 02-Окт-15, 11:07	+2 +/–
Это не просто Кабак. Это Маньяк на базе Кабака!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #41

14. Сообщение от абвгдейка (ok), 02-Окт-15, 11:09	+1 +/–
>Это computer science, в России малоизвестное. все с точностью до наоборот :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

16. Сообщение от Аноним (-), 02-Окт-15, 11:10	+20 +/–
И получает пару мегабайт малвари.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #56

17. Сообщение от тоже Аноним (ok), 02-Окт-15, 11:10	+5 +/–
Хороший вариант, но мне почему-то не нравится следующий шаг: "...и исполняет ее на компьютере пользователя, не зная, что она на самом деле делает". Пустое предубеждение, конечно. Разве сервер, отдающий картинки, может прислать в ответ на такой запрос, что-то, кроме программы для декодирования?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #100

18. Сообщение от Аноним (-), 02-Окт-15, 11:10	+/–
> Исходные тексты утилит и библиотеки для работы с форматом FLIF доступны под лицензией GPLv3 Не взлетит
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #30, #80

19. Сообщение от Аноним (-), 02-Окт-15, 11:18	+/–
Полагаю лучше бы сделали возможность указывать несколько файлов для одного изображения - варианты в разных форматах и разрешениях, а браузер сам определял в каком разрешении и формате ему удобнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #27, #50

20. Сообщение от Khariton (ok), 02-Окт-15, 11:25	–6 +/–
Оно то да. А вот где используется в реальной жизни картинка без сжатия? Если звук без жатия еще имеет какую-то нишу, то картинка, только в виде raw для специалистов по фотографии. Я думаю, они не будут для экономии места пережимать в FLIF ибо это время, и нужно только для бекапа... Это скорее всего узкая ниша типа медецины, геодезии и всяких военных направлений, где важнее достоверность, чем объем...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #22, #60

21. Сообщение от хрю (?), 02-Окт-15, 11:27	+1 +/–
Уже всё украдено. алгоритм декодирования на js, который можно получить из с через  Emscripten. Так что проблем с отображением любых форматов нет, есть только проблемы со скоростью этого отображения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #39

22. Сообщение от 10й Брейтовский переулок (?), 02-Окт-15, 11:29	+3 +/–
>> Это скорее всего узкая ниша типа медецины, геодезии и всяких военных направлений, где важнее достоверность, чем объем... Одного это уже на годы вперед хватит. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #23

23. Сообщение от Khariton (ok), 02-Окт-15, 11:49	–1 +/–
>>> Это скорее всего узкая ниша типа медецины, геодезии и всяких военных направлений, где важнее достоверность, чем объем... > Одного это уже на годы вперед хватит. :) Оно то так, но почему-то все пользуют ogg, mp3, jpeg, png... Про видео вообще молчу. Это массовое решение. Некоторые пользуют flac и иже с ними. Для личного пользования. Их процент малый. Про картинки - в основном только RAW. Железа (фотоаппарат, сканер, звукозапись), которое сразу пишет в flac или другой алгоритм сжатия без потерь (картинка, звук и т.д.) я что-то не припоминаю. Софта который активно с такими форматами без перекодировки работает(позволяет их изменять, обрабатывать) тоже малова-то. В основном только конечное пользование: просмотр, прослушивание... Надеемся, что терабайтная флешка через 5 лет станет так же популярна как 10 лет назад мегабайтная. А процессоры в бытовом железе будут на лету жать в эти форматы лучше чем джепег или огг. Тогда это станет нормой. ПиСя: Кстати жаль нет сравнения сжатия относительно xz.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #26, #70, #97, #114

24. Сообщение от Cdome (?), 02-Окт-15, 11:55	+2 +/–
Сравнение с BPG есть в новости, читайте внимательней
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

25. Сообщение от Aquarius (ok), 02-Окт-15, 11:59	+/–
ещё один формат для облаков
Ответить | Правка | Наверх | Cообщить модератору

26. Сообщение от Khariton (ok), 02-Окт-15, 12:01	+2 +/–
тестанул XZ: $ls -l P9172593.* ---  3818620 P9172593.JPG --- 23971389 P9172593.tif $ xz P9172593.tif ls -l P* ---  3818620 P9172593.JPG --- 13791152 P9172593.tif.xz неплохо пожало тиффку сделаную из джепега, почти в два раза. оригинальной raw-картинки жалко нет под рукой. Но жало несколько секунд на двухядерном ноутбуке(похоже одно ядро только работало) Разжимало быстрее. секунду где-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #43

27. Сообщение от клоун Соплежуй (?), 02-Окт-15, 12:02	–4 +/–
Ты явно к ИТ отношения не имеешь... Думаешь кто-то будет пересохранять файлы, тратя время и место на диске, лишь чтобы какой-нибудь бородатый клоун, фанатеющий от своего извращённого понимания "свободы", мог получить файл в истинно-православно-халяльно-свободном формате?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #37

28. Сообщение от yekm (ok), 02-Окт-15, 12:07	–2 +/–
Исходники соблазнительные, один файл всего. Не то что в Webp. А на bpg вообще страшно смотреть -- открываешь, а там libavcodec libavutil x265 треш угар и содомия. Картинка с котиками получилась больше оригинала -- 4.9М flif против 3.2М jpg. Нет, ну конечно меньше, чем 9.8М png, но мне и жпег обещали же!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32

29. Сообщение от bukazoid (??), 02-Окт-15, 12:08	+/–
Но дольше!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

30. Сообщение от Moomintroll (ok), 02-Окт-15, 12:10	+1 +/–
>> Исходные тексты утилит и библиотеки для работы с форматом FLIF доступны под лицензией GPLv3 > Не взлетит «Заложенные в формат технологии распространяются на условиях безвозмездного использования и не требуют патентных отчислений.» Иначе говоря, Вы можете реализовать алгоритм на любом языке под любой лицензией.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

31. Сообщение от orgkhnargh (ok), 02-Окт-15, 12:17	–9 +/–
Существование формата подразумевает наличие стандарта, описывающего этот формат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

32. Сообщение от tyuiop (?), 02-Окт-15, 12:21	+1 +/–
Читаем внимательно "lossless-режимы форматов ... JPEG2000"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #36

33. Сообщение от Аноним (-), 02-Окт-15, 12:23	–13 +/–
Нельзя просто так взять и "увеличить место на винте". Жесткий диск имеет заданную ёмкость. Можно лишь освободить ранее заданное место за счёт более эффективного сжатия файлов. Твой кеп.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #44

34. Сообщение от Аноним (-), 02-Окт-15, 12:24	+/–
> Больше, больше стандартов! Ещё 10 лет назад хомячки вроде тебя орали - даешь больше, больше выбора! Каптча 01000 подверждает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

35. Сообщение от Нимано (?), 02-Окт-15, 12:29	+/–
котики.jpeeg.exe?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

36. Сообщение от yekm (ok), 02-Окт-15, 12:31	–1 +/–
Ой, да. Простите, больше так не буду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #58, #64

37. Сообщение от annual slayer (?), 02-Окт-15, 12:43	+/–
srcset и <picture> это почти то же самое
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #51

38. Сообщение от Alexey (??), 02-Окт-15, 12:47	–2 +/–
Если они собираются продвигать свой новый формат, то лицензия GPL 3 этому точно будет мешать.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #45

39. Сообщение от Crazy Alex (ok), 02-Окт-15, 12:49	+/–
Там даже скорость довольно неплохая, кстати. Но костыль же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

40. Сообщение от Crazy Alex (ok), 02-Окт-15, 12:54	+1 +/–
Вот жаль, что ImageZero до ума не довели. Для всяких кэшей картинок в оперативке/на диске было бы в самый раз. Для браузеров, просмотрщиков PDF и подобного.
Ответить | Правка | Наверх | Cообщить модератору

41. Сообщение от КО (?), 02-Окт-15, 13:00	+2 +/–
Маньяк вышедший из Кабака :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #65

42. Сообщение от Вася (??), 02-Окт-15, 13:05	–3 +/–
эх... салабоны... Где же фрактальное сжатие? я в 90-х на дипломе сжимал круче чем джипег2000
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #46, #55, #66

43. Сообщение от t (??), 02-Окт-15, 13:14	+3 +/–
xz однопоточный. если надо использовать несколько ядер есть pxz, архив итоговый получается такой же, а время сокращает сильно (я бекапы теперь так и делаю), tar тоже может его понимать как параметр для архивации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #48, #95, #132

44. Сообщение от Sluggard (ok), 02-Окт-15, 13:24	+9 +/–
Товарищ имел ввиду свободное место на винте. И мне любопытно, ты выпендриться решил, или просто тугой?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #53

45. Сообщение от Moomintroll (ok), 02-Окт-15, 13:28	+2 +/–
> Если они собираются продвигать свой новый формат, то лицензия GPL 3 этому точно будет мешать. Вы тоже не различаете формат (алгоритм «на условиях безвозмездного использования и не требуют патентных отчислений») и код (реализацию GPL3)?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

46. Сообщение от Пользователь Debian (?), 02-Окт-15, 13:29	+7 +/–
Не отвлекайся, пиши дальше обработку на 1С.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

48. Сообщение от Khariton (ok), 02-Окт-15, 13:31	+/–
> xz однопоточный. если надо использовать несколько ядер есть pxz, архив итоговый получается > такой же, а время сокращает сильно (я бекапы теперь так и > делаю), tar тоже может его понимать как параметр для архивации. вау. буду знать. полезность. про tar я знал...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

49. Сообщение от fi (ok), 02-Окт-15, 13:47	+/–
Уже есть, только ссылка ведет на сайт производителя кодека - а ты уже решаешь - нужен ли он тебе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

50. Сообщение от fi (ok), 02-Окт-15, 13:48	+1 +/–
> Полагаю лучше бы сделали возможность указывать несколько файлов для одного изображения > - варианты в разных форматах и разрешениях, а браузер сам определял > в каком разрешении и формате ему удобнее. Собственно это есть даже в стандарте HTTP 1.0 - поле accept
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

51. Сообщение от клоун Соплежуй (?), 02-Окт-15, 13:51	–2 +/–
Над этим уже постебались http://pepelsbey.net/pres/picture/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #61

52. Сообщение от Зенитарка (?), 02-Окт-15, 14:05	+11 +/–
Т.е. я могу сжимать данные, и при этом не терять?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #57, #92

53. Сообщение от Аноним (-), 02-Окт-15, 14:06	–2 +/–
Надо стараться правильно излагать мысли, хоть некоторым это затруднительно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

55. Сообщение от Crazy Alex (ok), 02-Окт-15, 14:11	+3 +/–
Ну вот к тебе и вопрос тогда - где?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

56. Сообщение от Аноним (-), 02-Окт-15, 14:11	+/–
Браузеров не так уж и много. Можно завести репозиторий с подписанными кодеками, которые, при необходимости, скачивались автоматически.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #63

57. Сообщение от клоун Соплежуй (?), 02-Окт-15, 14:12	+/–
Именно. Я уже пережимаю JPEG и советую тебе сделать так же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

58. Сообщение от Moomintroll (ok), 02-Окт-15, 14:17	+/–
> Спецификации (алгоритма) нет. Может всё-таки будет… На официальном сайте: «WARNING: FLIF is a work in progress. The format is not finalized yet.»
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

60. Сообщение от нонайм (?), 02-Окт-15, 14:37	+/–
картографические архивы.. медицинские архивы.. поля распаханные давно, а тут новые тракторы.. где-то обязательно перейдут со временем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #74, #136

61. Сообщение от Moomintroll (ok), 02-Окт-15, 14:58	+/–
> внутреннего API ядра Ну нет, ядро не из этого списка, потому что https://www.kernel.org/doc/Documentation/stable_api_nonsense... Т.е. никто и не обещает стабильный API в ядре.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

63. Сообщение от тоже Аноним (ok), 02-Окт-15, 15:17	+5 +/–
Натурально, вы не понимаете. Если создатели браузеров хотят поддерживать форматы, то они поддерживают форматы, а если не хотят - то и все описанные вами странные телодвижения в браузере реализовывать никто не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #102

64. Сообщение от Аноним (-), 02-Окт-15, 15:34	+/–
>фанатикам то свинина мешает, то DRM не знаю людей кому ДРМ бы не мешала
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #67

65. Сообщение от виндотролль (ok), 02-Окт-15, 15:36	+3 +/–
Модератор, вычисли всех этих по IP и отправь в цирк.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #69

66. Сообщение от СамТакой (?), 02-Окт-15, 15:37	+1 +/–
Сжимал. А расжимал потом?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #68

67. Сообщение от клоун (?), 02-Окт-15, 15:47	–1 +/–
Нерепрезентативно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

68. Сообщение от клоун Соплежуй (?), 02-Окт-15, 16:02	–1 +/–
Придумать свой формат, который жмёт лучше существующего коммерческого - это типовой курсовой/дипломный проект. Лайфхак 1: сделать N вызовов существующих архиваторов с разными настройками, изменить расширение - БИНГО! Теперь можно писать об успехах: - всех дрюкнул - создаваемые ТВОИМ алгоритмом архивы совместимы с существующими unpack'ерами Лайфхак 2. Просишь папу, друга, брата, свата и пр. подписать акт о внедрении. Проверяющие в восторге: у них внедрения в отдельной строке эффективности ВУЗа прописаны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

69. Сообщение от тоже Аноним (ok), 02-Окт-15, 16:07	+3 +/–
Учитель наш Кун говорил: "Не пошутишь - и не весело".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

70. Сообщение от Mihail Zenkov (ok), 02-Окт-15, 16:15	+3 +/–
> Железа (фотоаппарат, сканер, звукозапись), которое сразу пишет в flac или другой алгоритм сжатия без потерь (картинка, звук и т.д.) я что-то не припоминаю. Звуковые платы и сканеры выдают поток без сжатия. Плееры с rockbox'ом тоже могут писать без сжатия. Хорошие фотоаппараты выдают - raw или tiff. > Софта который активно с такими форматами без перекодировки работает(позволяет их изменять, обрабатывать) тоже малова-то. В основном только конечное пользование: просмотр, прослушивание... gimp/audacity/avidemux/blender и весь остальной софт, ориентированный на создание и обработку мультимедиа. Многие 3d-шники рендерят анимацию как серию png, так как это самый переносимый способ получения видео без сжатия с альфа каналом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

71. Сообщение от Нимано (?), 02-Окт-15, 16:23	+1 +/–
> Что толку от таких спецификаций и стандартов? Дети решили поиграть во взрослых: > придумывают стандарты, пишут спецификации. Стесняюсь спросить – а можно ссылочку на спеки NTFS?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #77

72. Сообщение от arisu (ok), 02-Окт-15, 16:25	+/–
(вздыхает) ещё один. несмотря на интересные фичи… даже у гугеля с вебп не очень как‐то получилось. ой, reference на цпп. тьфу, гадость какая. а казался нормальным проектом.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #105

73. Сообщение от Pilat (ok), 02-Окт-15, 16:36	+1 +/–
Losеless это хорошо, но чаще нужно сжать с потерями. И тут все конкуренты тихо сливаются по сравнению с Dejavu - он в пять раз уменьшает хорошие JPEG (высокого разрешения с фотоаппарата, стоковые фото и подобное). 20% от JPEG - с очень незначительной потерей качества.
Ответить | Правка | Наверх | Cообщить модератору

74. Сообщение от anonymous (??), 02-Окт-15, 16:42	–1 +/–
Тут рулит и педалит JPEG2000, причем часто используется режим с потерями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #75

75. Сообщение от клоун Соплежуй (?), 02-Окт-15, 16:51	+/–
Чуваки просто не понимают, что когда разрешающая способность ниже, чем максимальные потери, то уже не важно будет сжатие или нет. Это как с бытовыми музыкальными проигрывателями и колонками/аудиокартами, качество которых зачастую недостаточно для воспроизведения flac, а покупатели не готовы платить за аппаратуру требуемого качества. Вот и получается, что flac это на 99% дешёвые по-ты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #76, #96, #141

76. Сообщение от arisu (ok), 02-Окт-15, 16:55	+11 +/–
flac — это возможность конвертации в любой формат с потерями по необходимости. я, например, использую исключительно ворбис, а качаю исключительно флаки. желающим делать ворбис из mp3 — привет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #130

77. Сообщение от клоун Соплежуй (?), 02-Окт-15, 16:55	–2 +/–
Вот мы и пришли к вопросу что лучше: лекарство, срок годности которого ты не знаешь, или лекарство с просроченным сроком годности. На эту тему (дефицит информации VS недостоверная информация) шутил ещё Льюис Кэролл (автор Алисы в стране чудес): часы, которые стоят, показывают точное время чаще, чем часы, которые спешат на 5 минут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #81

80. Сообщение от Аноним (-), 02-Окт-15, 18:11	+/–
>> Исходные тексты утилит и библиотеки для работы с форматом FLIF доступны под лицензией GPLv3 > Не взлетит Взлетит
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

81. Сообщение от Нимано (?), 02-Окт-15, 18:19	+1 +/–
> Вот мы и пришли к вопросу что лучше: лекарство, срок годности которого > ты не знаешь, или лекарство с просроченным сроком годности. Т.е. конкретики типа ссылок на доки НТФС –  не будет, а будет очередное жонглирование словами. Окай. > На эту тему (дефицит информации VS недостоверная информация) Ссылочку на "недостоверную информацию" можно? А то пока выходит "недостаточная/неполная документация некоторых проектов" VS. "индейское национальное жилище вам, а не спеки с доками или, тем более, сырцами!".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

82. Сообщение от Sinot (ok), 02-Окт-15, 18:37	+/–
>В основе FLIF лежит статистический алгоритм контекстно-адаптивного двоичного арифметического кодирования MANIAC (Meta-Adaptive Near-zero Integer Arithmetic Coding), который является одним из вариантов алгоритма CABAC (Context-Adaptive Binary Arithmetic Coding), также используемого при кодировании видео H.264 Есть подозрение, что MPEG LA это дело отчислениями покроет если взлетит.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #83

83. Сообщение от arisu (ok), 02-Окт-15, 18:53	+2 +/–
патенты на арифметику истекли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

84. Сообщение от Аноним (-), 02-Окт-15, 19:41	–3 +/–
> Проблема то актуальная. Популярная картинка может генерировать терабайты трафика. > http://i.imgur.com/wU8sdky.png?1 Открой для себя кэширующие прокси.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

92. Сообщение от анонимус (??), 02-Окт-15, 19:48	–1 +/–
Я у себя локально пережал все png-шки без потерь с помщью RIOT. Поразило, что размер многих уменьшился аж вдвое. RIOT умеет урезать палитру (нафига, например, нужна труколор-палитра, если файл 256-цветный) и прогоняет получившееся через внешние подключаемые компрессоры типа optipng.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

95. Сообщение от Michael Shigorin (ok), 02-Окт-15, 21:05	+1 +/–
> если надо использовать несколько ядер есть pxz, архив итоговый получается такой же Помнится, автор писал, что всё-таки чуть толще, но обычно ненамного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

96. Сообщение от Crazy Alex (ok), 02-Окт-15, 21:29	+2 +/–
Предлагаете после замены аппаратуры выкинуть коллекцию и создавать заново? Плюс лосслесс позволяет не задумываться, достаточно ли хорошо сжатие - а то выяснить, ниже разрешающая способность или нет - задача нетривиальная. Хотя, что это я - клоуну отвечаю? А не пошёл бы он лучше в цирк, прыгать там по команде дрессировщика.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #99

97. Сообщение от Алексей (??), 02-Окт-15, 23:07	+1 +/–
> Оно то так, но почему-то все пользуют ogg, mp3, jpeg, png... Про Сам PNG перечислил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #98

98. Сообщение от Алексей (??), 02-Окт-15, 23:10	+/–
>> Оно то так, но почему-то все пользуют ogg, mp3, jpeg, png... Про > Сам PNG перечислил. Ах, без _сжатия_, а не без _потерь_… Ну, имелось в виду же пережать то, что не сжато с потерями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

99. Сообщение от клоун Засранчик (?), 03-Окт-15, 00:19	+/–
Ну да, ну да... А при покупке автомобиля нужен 5-тонный грузовик (ну а вдруг понадобиться), способный разгоняться до 300 км/ч (ну а вдруг). Чё, под каждую задачу свою машину создавать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #103, #104

100. Сообщение от Аноним (-), 03-Окт-15, 00:38	+/–
Так браузер может ограничить возможности декодера: читать данные из полученного файла, выводить результат декодирования в строго заданный буфер и ничего больше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #108

101. Сообщение от Аноним (-), 03-Окт-15, 06:05	+/–
Image Compression With an Auto-Indexing and Context-Learning MANIAC https://drive.google.com/file/d/0BwMTfsYj-_l6eWZWRHg3RGtwQW8...
Ответить | Правка | Наверх | Cообщить модератору

102. Сообщение от Аноним (-), 03-Окт-15, 07:47	+/–
В репу могут добавлять независимые разрабы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #107

103. Сообщение от Mihail Zenkov (ok), 03-Окт-15, 10:35	+/–
Ваша аналогия не совсем корректна, лучше подходит аналогия с гаражом: если в будущем есть большая вероятность покупки машины бОльших габаритов, чем та что уже есть, то лучше сразу построить гараж с запасом. А так согласен, нужно все выбирать исходя из задачи: для плеера в шумных условиях - mp3/vorbis 192-320kbps для аудиокниг - 128kbps вполне хватает для хорошей музыкальной коллекции - flac
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #119

104. Сообщение от Crazy Alex (ok), 03-Окт-15, 10:59	+/–
Если разница в затратах между этим монстром и малолитражкой на двоих - копейки, то именно так и предлагаю. А впаривать кучу "вариантов", которые реально ничем не отличаются - это привычка ублюдков вроде Майкрософта с их версиями винды.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99

105. Сообщение от Crazy Alex (ok), 03-Окт-15, 11:07	+/–
Там очень понятные и по делу использованные плюсы. Не знаю, что тебе не так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #110, #112

106. Сообщение от Аноним (-), 03-Окт-15, 11:33	–2 +/–
> анимации зачем?? :-(
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #111

107. Сообщение от тоже Аноним (ok), 03-Окт-15, 11:49	+1 +/–
В репу кто угодно может, а вот в браузер - нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

108. Сообщение от тоже Аноним (ok), 03-Окт-15, 11:52	+/–
А кофе принести, пока декодер работает, браузер не может? Весь контроль, который есть у браузера над произвольным кодом, ограничивается управлением входом и выходом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #109

109. Сообщение от Crazy Alex (ok), 03-Окт-15, 14:20	+/–
Ну,еоретически так обрезать декодер можно, а на практике - сначала хзахотят доступ к SSE, потом - к GPU, потом решат, что нужен DRM со взаимодействием с аппаратным чипом и дополнитльеными запросами в сеть... и так далее, и тому подобное. В сущности, то, что в браузере есть JS уже очень печально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #113

110. Сообщение от arisu (ok), 03-Окт-15, 16:26	+1 +/–
> Там очень понятные и по делу использованные плюсы. Не знаю, что тебе > не так. плюсы не так. вот когда у плюсов хотя бы стандарты на манглинг, vmt, вызовы появятся — вот тогда можно будет на плюсах. когда я возьму собраную пять лет назад gcc3 плюсовую библиотеку, и спокойно слинкую с только что написаным плюсовым кодом, собраным gcc5. мне не сам язык не нравится — хоть на суахили пусть делают, всё равно, — мне не нравится то, что линковка с c++ — это лишние проблемы за мои деньги, как говорится. так что пусть уносит своё поделие назад, и выносит реализацию на «стандартном» языке, то бишь си. или GTFO.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

111. Сообщение от arisu (ok), 03-Окт-15, 16:27	+2 +/–
>> анимации > зачем?? :-( иди‐иди, ты флэш обновить забыл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

112. Сообщение от arisu (ok), 03-Окт-15, 16:28	+/–
> Там очень понятные и по делу использованные плюсы. Не знаю, что тебе > не так. а в остальном оно прикольное, конечно. особенно мне понравилась фича с недокачаной анимацией — такой точно ни у кого нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

113. Сообщение от arisu (ok), 03-Окт-15, 16:40	+/–
> Ну,еоретически так обрезать декодер можно, а на практике - сначала хзахотят доступ > к SSE, потом - к GPU, потом решат, что нужен DRM > со взаимодействием с аппаратным чипом и дополнитльеными запросами в сеть... и > так далее, и тому подобное. ну да, ведь в браузер ещё не встроили «настоящую» виртуальную машину. без виртуальной машины, эмулирующей реальный процессор, браузер неполноценен, ящитаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

114. Сообщение от Аноним (-), 03-Окт-15, 17:40	+/–
>>Некоторые пользуют flac и иже с ними. Для личного пользования. Их процент малый. Фигню сморозил. Купи диск любимой группы и увидишь, что там будет lossless.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #115

115. Сообщение от axredneck (?), 03-Окт-15, 20:44	–2 +/–
Вот только диски-то сейчас покупают разве что очень-меломаны, большинство же довольствуется мрЗ. И то некоторые меломаны предпочитают винил, а он, извините, lossy, потому что аналоговый.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #117

117. Сообщение от Аноним (-), 05-Окт-15, 09:24	+2 +/–
наоборот :) это оцифровка аналога порождает ошибки и приближения.. man Теорема Котельникова.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #118

118. Сообщение от count0krsk (ok), 05-Окт-15, 20:01	–1 +/–
Все звуки в мире аналоговые. Что теперь, на аудиокассеты писать? И как быть с тем, что записанное в 30-50 годы прошлого века (слушаю Джаз, лаундж и т.п.) на слух звучит заметно хреновей, хотя и писалось на супер-пупер аналог? Включаешь современную запись - как сидишь в студии рядом с группой. И глубина, и ширина... Правда души меньше, но это уже субъективно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117

119. Сообщение от count0krsk (ok), 05-Окт-15, 20:13	–2 +/–
> Ваша аналогия не совсем корректна, лучше подходит аналогия с гаражом: если в > будущем есть большая вероятность покупки машины бОльших габаритов, чем та что > уже есть, то лучше сразу построить гараж с запасом. > А так согласен, нужно все выбирать исходя из задачи: > для плеера в шумных условиях - mp3/vorbis 192-320kbps > для аудиокниг - 128kbps вполне хватает > для хорошей музыкальной коллекции - flac Не, кто бы спорил, что лучше быть здоровым и богатым, чем бедным и больным. Но у нас тут, в Сибири, 7000 руб на лишний 2Тб винт как бы играют роль. Это как бы 2 недели еды на 1го человека. Если экономить. Поэтому разницу в 320 мп3 и 800 кбит флак можно и не заметить, а вот пустое брюхо или синяк от жены - вполне ))) Ну и какбы на плеер замучаешься кидать, если надо по-быстрому скачанное забросить и побежать по-делам, а там вместо 300 Мб VBR будет 1.5 Гб... Так что для понтовозов и ценителей это. Я одинаково не люблю как ламповый др*ч, так и любителей hi-res stereo и прочих флаков, кабелей до колонок толщиной в руку с 99.999 чистотой меди. Делать нечего людям и деньги некуда девать ИМХО.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #120

120. Сообщение от Mihail Zenkov (ok), 05-Окт-15, 21:07	+/–
> Не, кто бы спорил, что лучше быть здоровым и богатым, чем бедным > и больным. Но у нас тут, в Сибири, 7000 руб на > лишний 2Тб винт как бы играют роль. Это как бы 2 > недели еды на 1го человека. Если экономить. Поэтому разницу в 320 > мп3 и 800 кбит флак можно и не заметить, а вот > пустое брюхо или синяк от жены - вполне ))) Тут стоит задуматься, а надо ли вам 2TB музыки? Во флаке это примерно 5500ч, если слушать даже по 8ч в сутки, то понадобится 687 дней, чтобы один раз все это послушать. > Ну и какбы на плеер замучаешься кидать, если надо по-быстрому скачанное забросить > и побежать по-делам, а там вместо 300 Мб VBR будет 1.5 > Гб... Я для таких целей использую mp3fs. > Так что для понтовозов и ценителей это. Я одинаково не > люблю как ламповый др*ч, так и любителей hi-res stereo и прочих > флаков, кабелей до колонок толщиной в руку с 99.999 чистотой меди. > Делать нечего людям и деньги некуда девать ИМХО. У каждого свои критерии качества звука. Но как не крути - нельзя выкинуть 75% информации и ничего при этом не потерять. Flac еще интересен тем, что мало нагружает процессор (примерно в два раза меньше mp3), что может положительно сказаться на времени автономной работы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #121, #128

121. Сообщение от arisu (ok), 05-Окт-15, 21:37	+/–
> Тут стоит задуматься, а надо ли вам 2TB музыки? Во флаке это > примерно 5500ч, если слушать даже по 8ч в сутки, то понадобится > 687 дней, чтобы один раз все это послушать. одно из свойств музыки такое, что её не всегда есть желание слушать «подряд». и ещё одно — что захочется послушать, предсказать не всегда возможно. поэтому лично у меня копится довольно большой объём того, что я могу слушать раз в несколько лет — но, тем не менее, когда я захочу это послушать, желательно это иметь. это я так, лирическое отступление написал. > Flac еще интересен тем, что мало нагружает процессор > (примерно в два раза меньше mp3), что может положительно > сказаться на времени автономной работы. а вот это, кстати, немаловажно. а ворбис ещё больше ресурсов требует, чем mp3, насколько я помню.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #122

122. Сообщение от Mihail Zenkov (ok), 05-Окт-15, 22:01	+1 +/–
> одно из свойств музыки такое, что её не всегда есть желание слушать > «подряд». и ещё одно — что захочется послушать, предсказать не всегда > возможно. поэтому лично у меня копится довольно большой объём того, что > я могу слушать раз в несколько лет — но, тем не > менее, когда я захочу это послушать, желательно это иметь. Согласен, но если в течении 5 лет такого желания не возникло, то можно удалять :) У меня на данный момент 200GB музыки, большая часть - flac. 50% - потенциальные кандидаты на удаление. Музыку я очень люблю и дом проектирую с учетом архитектурной акустики (в будущем будет домашняя студия звукозаписи). Но музыки, которую интересно слушать больше пары раз, не так уж и много. Раньше собирал полные дискографии, затем стал оставлять только интересные альбомы, теперь не считаю святотатством удаление неинтересных треков с альбома. Бывает что из всего творчества группы остается один-два трека. > а вот это, кстати, немаловажно. Важно, но не всегда. Например у sansa zip/clip общее потребление по питанию падает только на 10-15%. > а ворбис ещё больше ресурсов требует, чем > mp3, насколько я помню. Да. А opus еще больше, но возможно он еще не полностью оптимизирован.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #123

123. Сообщение от arisu (ok), 05-Окт-15, 22:11	+/–
> Согласен, но если в течении 5 лет такого желания не возникло, то > можно удалять :) не факт. я, например, Янку очень редко слушаю, но когда хочется — тут лучше, чтобы была под рукой, потому что совсем не то настроение, чтобы искать, качать… > Но музыки, которую интересно слушать больше пары раз, не так уж > и много. Раньше собирал полные дискографии, затем стал оставлять только интересные > альбомы, теперь не считаю святотатством удаление неинтересных треков с альбома. Бывает > что из всего творчества группы остается один-два трека. я пока что держу дискографии — в основном потому, что обычно не хватает терпения прослушать все альбомы и оставить только самые интересные. :-) с другой стороны, я сейчас и музыки‐то качаю совсем немного: как оказалось, я собрал вполне достаточно, чтобы найти в коллекции что‐нибудь на любое настроение. благо, это не современные видеоигры, можно переслушивать много раз совершенно без потери удовольствия. > Да. А opus еще больше, но возможно он еще не полностью оптимизирован. к счастью, в опусе музыки ещё не видел. а вот в ворбис кодирую, потому что по идеологическим причинам не люблю mp3.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #124

124. Сообщение от Mihail Zenkov (ok), 05-Окт-15, 22:25	+/–
> к счастью, в опусе музыки ещё не видел. а вот в ворбис > кодирую, потому что по идеологическим причинам не люблю mp3. У opus сжатие еще сильнее, чем у vorbis. С открытостью тоже вроде все в порядке. Его минусы - больше грузит проц и меньше распространенность/поддержка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #125

125. Сообщение от arisu (ok), 05-Окт-15, 22:31	+/–
> У opus сжатие еще сильнее, чем у vorbis. насколько помню, это компенсируется уменьшеным диапазоном. впрочем, могу ошибаться, давно любопытствовал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #126

126. Сообщение от Mihail Zenkov (ok), 05-Окт-15, 22:41	+/–
> насколько помню, это компенсируется уменьшеным диапазоном. впрочем, могу ошибаться, давно > любопытствовал. Нет, он субъективно звучит лучше, при одинаковом битрейте. http://www.opus-codec.org/comparison/ http://listening-test.coresv.net/results.htm
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #127

127. Сообщение от arisu (ok), 05-Окт-15, 23:06	+/–
спасибо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126

128. Сообщение от count0krsk (ok), 06-Окт-15, 04:12	–1 +/–
> У каждого свои критерии качества звука. Но как не крути - нельзя > выкинуть 75% информации и ничего при этом не потерять. > Flac еще интересен тем, что мало нагружает процессор (примерно в два раза > меньше mp3), что может положительно сказаться на времени автономной работы. Да ладно уж, 75% ))) Видел сравнение mp3 320 и flac. Перекодировали в wav и из одного вычли другое. Получились частоты выше 17 КГц. Вы слышите такое? Я нет. Если конечно врубить синус только 17 КГц на хорошей акустике, да громкость выкрутить раза в 2-3 больше обычной, то какой-то пиии и можно услышать. Но при обычном прослушивании высокие частоты кроме того что хуже "усваиваются" ухом, так ещё и маскируются более низкими, как например голос маскируется звуком проезжающего поезда. Поэтому те кто более-менее "шарит" понимают что в реальной музыке на средней громкости они выше 14 КГц не услышат. И некоторые даже довольствуются широкополосными динамиками, которые выше 14 не играют, зато вся остальная полоса более ровная. Но это лирика )) У меня сейчас 212 Гб музыки. Если перевести во флак, будет Гб 600. Плюс бэккап, получаем 1.2 Тб. Плюс ещё на твердые носители надо это всё нарезать периодически, ну не доверяю я жестким дискам самое ценное ) Даже на двуслойках у меня много места это всё занимает, а тут в 3 раза больше...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #129

129. Сообщение от Mihail Zenkov (ok), 06-Окт-15, 11:28	+/–
> Да ладно уж, 75% ))) Видел сравнение mp3 320 и flac. Перекодировали > в wav и из одного вычли другое. Получились частоты выше 17 > КГц. Не так все просто. mp3 320 меньше flac в 3-5 раз. 22kHz / 17kHz = 1.3 раза. Где все остальное? Да и даже их нельзя просто так срезать - в этот диапазон (18-22kHz) выносится шум, вызываемый борьбой с ошибкой округления (noise shaping). > Вы слышите такое? Я нет. Если конечно врубить синус только > 17 КГц на хорошей акустике, да громкость выкрутить раза в 2-3 > больше обычной, то какой-то пиии и можно услышать. Согласен - выше 16-17 kHz малозначимые детали (верхние обертона). > Но при обычном > прослушивании высокие частоты кроме того что хуже "усваиваются" ухом, так ещё > и маскируются более низкими, как например голос маскируется звуком проезжающего поезда. Некорректный пример - у поезда и средние частоты громче голоса. Но согласен, эффект маскировки есть, но работает он иначе. Психоаккустика помогает выделить основные детали и второстепенные. Но это не значит, что можно пожертвовать второстепенным и никто этого не заметит. Все зависит от ситуации и что бы не гадать, а не потерял ли что-то любимый трек/альбом, проще хранить его во flac. > Поэтому те кто более-менее "шарит" понимают что в реальной музыке на > средней громкости они выше 14 КГц не услышат. И некоторые даже > довольствуются широкополосными динамиками, которые выше 14 не играют, зато вся остальная > полоса более ровная. Но это лирика )) Как любитель ШП, отмечу что полоса у них не ровная, больше подкупает относительная точечность излучения и высокая чувствительность. > У меня сейчас 212 Гб музыки. Если перевести во флак, будет Гб > 600. Плюс бэккап, получаем 1.2 Тб. Плюс ещё на твердые носители > надо это всё нарезать периодически, ну не доверяю я жестким дискам > самое ценное ) Даже на двуслойках у меня много места это > всё занимает, а тут в 3 раза больше... Так может лучше удалить лишнее? В вашем случае это будет существенно эффективнее любого сжатия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #134

130. Сообщение от Ilya Indigo (ok), 07-Окт-15, 21:30	+/–
Откройте для себя уже opus. Или его в слаке до сих пор нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #131

131. Сообщение от arisu (ok), 07-Окт-15, 21:33	+/–
не проецируй: пользователи слаквари умеют собирать из исходных текстов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #133

132. Сообщение от анонимный_анонимус (?), 08-Окт-15, 02:11	+/–
из man xz:        -T threads, --threads=threads               Specify  the  number  of worker threads to use.  Setting threads to a special value 0 makes xz use as many threads as there are CPU cores on the system.  The actual number of               threads can be less than threads if the input file is not big enough for threading with the given settings or if using more threads would exceed the memory usage limit.               Currently the only threading method is to split the input into blocks and compress them independently from each other.  The default block  size  depends  on  the  compression               level and can be overriden with the --block-size=size option.               Threaded  decompression hasn't been implemented yet.  It will only work on files that contain multiple blocks with size information in block headers.  All files compressed in               multi-threaded mode meet this condition, but files compressed in single-threaded mode don't even if --block-size=size is used.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

133. Сообщение от Ilya Indigo (ok), 09-Окт-15, 15:23	+/–
> не проецируй: пользователи слаквари умеют собирать из исходных текстов. Уметь и делать отнюдь не одно и тоже. :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131

134. Сообщение от count0krsk (ok), 09-Окт-15, 20:31	–1 +/–
Да не найду я это всё во флаке, что за годы собрал, как раз удаляя лишнее. С местом-то нет проблемы. Просто поспорить чуток хотелось ))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

135. Сообщение от Аноним (-), 14-Окт-15, 15:26	+/–
Написано на божественном C++, а не на Си, - уже огромный плюс.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #138

136. Сообщение от Аноним (-), 17-Июл-16, 17:41	+/–
> картографические архивы.. медицинские архивы.. поля распаханные давно, а тут новые тракторы.. > где-то обязательно перейдут со временем. не, там или FIF, LWF или ECW или лютая проприетарь под которую плагины даже для GIMP и xnview полусырые(из 7 специфичных для медицины и 4 для космоса - только три поддерживаются). зато часть алгоритмов обработки из - заюзана в части фильтров )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

137. Сообщение от Аноним (-), 17-Июл-16, 17:44	+/–
> Очень неплохие результаты. > Хотелось бы сравнение FLIF с BPG. зависит от сжимаемого но от 1/5 до 1/4 выигрыша и от него, что СОлидно на мой взгляд. круче только античный FIF наверное в режиме с плавающей точкой и без ограничений по сложности и длительности кодирования, дефолтных(вэйвлетные алгоритмы - сильно пожиже хотя стастичные/однокадровые вариации dirac/shroedinger-а и покрытого мхом snow/nut-а - нехило и тут смотрятся)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

138. Сообщение от Аноним (-), 17-Июл-16, 17:45	+/–
> Написано на божественном C++, а не на Си, - уже огромный плюс. угу. надо только аглоритм переименовать а то "регуляторы" не поймут. "ишь развелось тут, МАНЬЯКОВ разных! и ходют и ходют, окаянные !! *махнул воображаемой клюшкой*"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135

139. Сообщение от Онаним (?), 19-Янв-17, 14:08	+/–
А что сейчас самое лучшее в lossy? Чтобы было сравнимо с JPEG по степени сжатия и на сколько это вообще возможно превосходило его по качеству?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #140

140. Сообщение от Ilya Indigo (ok), 19-Янв-17, 18:40	+/–
> А что сейчас самое лучшее в lossy? Чтобы было сравнимо с JPEG > по степени сжатия и на сколько это вообще возможно превосходило его > по качеству? opus
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

141. Сообщение от Аноним (141), 26-Июн-25, 14:52	+/–
>Вот и получается, что flac это на 99% дешёвые по-ты. Если слушать — да. А если как-то обрабатывать, например, делать из песен минусовки, ремиксы и т.п., то уже вполне полезная штука.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #71

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема