Message-ID: <666b7b6c@news.ausics.net> From: not@telling.you.invalid (Computer Nerd Kev) Subject: Re: Script to conditionally find and compress files recursively Newsgroups: comp.os.linux.misc References: User-Agent: tin/2.0.1-20111224 ("Achenvoir") (UNIX) (Linux/2.4.31 (i586)) NNTP-Posting-Host: news.ausics.net Date: 14 Jun 2024 09:06:21 +1000 Organization: Ausics - https://newsgroups.ausics.net Lines: 30 X-Complaints: abuse@ausics.net Path: csiph.com!news.bbs.nz!news.ausics.net!not-for-mail Xref: csiph.com comp.os.linux.misc:56567 Anssi Saari wrote: > J Newman writes: > >> It's true that you cannot tell within the first 5 seconds what the >> ultimate compression ratio will be, but it seems to me (from >> compressing avi/mp4/mov files with lzma -9evv) that you can tell >> within +/- 5% to a high degree of confidence, what the ultimate >> compression ratio will be given the first 5 seconds. > > Well then, I believe the solution was already posted. Grab 5% of your > files with dd and see how it compresses. The solution that I see grabs the first 1MB, but it would make more sense to sample eg. 1% of the file size in five places within the file. 100MB file = 1MB sample, 100MB/5 = 20MB, so use dd to grab one 1MB sample from the start of the file then four more at an offset that increments by 20MB each time. Store these separately, compress them separately, then average the compression ratio of all the samples. > I'm a little curious, what kind of space savings do you expect to get by > doing this? And wouldn't it make more sense to re-encode for lower > bitrate if space saving is your goal? Maybe he's using lossless video compression? Otherwise yes it seems like the wrong approach. -- __ __ #_ < |\| |< _#