7zip на несколько терабайт, диск уже сжатый

354
Don Mick

Итак, у меня есть диск, который является NTFS. он имеет тысячи графических / видео файлов, которые составляют около 6 ТБ. Я хотел сжать и отправить эту информацию кому-то.

Какой мой лучший вариант для сжатия? Я также заметил, что на дисководе установлен файловый менеджер: «сжать этот диск для экономии места на диске»

Когда я начинаю использовать 7zip для данных, общая сумма больше, чем я ожидал, например 8 ТБ или 9 ТБ, что, как я предполагаю, связано с тем, что сжатие диска включено.

Я пробовал Keka на Mac, но он идет чертовски медленно. Какие у меня есть варианты, чтобы получатель не получил поврежденные данные? В настоящее время я пытаюсь использовать формат 7zip и «store» для сжатия. Спасибо!

1
Как вы планируете передавать данные? Если это через Интернет, я бы предложил использовать rsync с включенным сжатием. Это должно быть как можно лучше без перекодировки самих файлов. confetti 5 лет назад 0
[* Алгоритмы сжатия данных без потерь не могут гарантировать сжатие для всех наборов входных данных. Другими словами, для любого алгоритма сжатия данных без потерь будет входной набор данных, который не становится меньше при обработке алгоритмом, а для любого алгоритма сжатия данных без потерь, который уменьшает по меньшей мере один файл, будет по меньшей мере один файл, который он увеличивает * * (https://en.wikipedia.org/wiki/Lossless_compression#Limitations). Поскольку мультимедийные файлы уже сжаты, их очень трудно сжать дальше, и этот набор, скорее всего, расширится при повторном сжатии. phuclv 5 лет назад 1

1 ответ на вопрос

0
confetti

Алгоритмы сжатия мало влияют на медиа-файлы.

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

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

Недавно я опробовал множество алгоритмов (zip, gzip, xz, bzip, lzma - все включено --best) в моей медиатеке (фильмы, телепередачи, музыка), и это не дало вообще никакого эффекта. Для некоторых файлов размер даже увеличивался.

Единственный действительно эффективный способ уменьшить размеры файлов - перекодировать медиафайлы. В зависимости от типа носителя это будет означать уменьшение разрешения, количества кадров в секунду, качества (например, цветовых пространств) или уменьшение битрейта. В некоторых случаях вы также можете изменить контейнер во время перекодирования. Например: аудиофайл FLAC объемом 100 МБ может иметь размер только 5 МБ, если кодируется в формате MP3 со скоростью 120 Кбит / с и переменной скоростью передачи битов.

Изменение кодека также имеет эффект, например, H265 вдвое лучше, чем H264, что, в свою очередь, было намного лучше, чем MPEG2 в DVD. Но, конечно, вы потеряете качество при перекодировании файлов phuclv 5 лет назад 1
С H265 вы можете сохранять отличное качество при гораздо меньшем размере файла, однако H265 не так хорошо поддерживается на всех устройствах и потребляет намного больше ресурсов ЦП во время воспроизведения. confetti 5 лет назад 0
Эй, ребята, OP здесь, я обеспокоен тем, что архив приходит без искажений, поэтому я должен просто сделать один гигантский файл .zip или .7zip размером 6 ТБ или разделить его на куски, например, несколько сотен гигабайт или 1-2 ТБ кусочек. Don Mick 5 лет назад 0
Это серьезно зависит от того, как вы планируете отправить его. Я бы по-прежнему предлагал rsync с включенным сжатием (`-z`), без архивирования или упаковки. Используя флаг `--partial`, вы можете возобновить передачу файла в случае неудачи, поэтому я бы посоветовал использовать его тоже. confetti 5 лет назад 0
это будет частной удаленной / облачной доставкой в ​​моей компании. Я бы отправил его через службу передачи файлов, которая довольно надежна. Я сделал это однажды с файлом 2TB, и у клиента не было никаких проблем. Don Mick 5 лет назад 0
Это зависит от вас, расщепление, вероятно, будет безопаснее. confetti 5 лет назад 0