similar to: More than 150 MB / second encoding + "nanozip"

Hello, Is there some version of FLAC that allows very very fast encoding (i.e. able to process at least 150 MB / second of .wav input data on a standard computer : laptop computer, Core i5/i7, Windows 7 64 bit, 8 GB RAM) ? (It's ok to have a compression ratio which is a little bit lower than traditionnal FLAC) I'm looking for something which is between FLAC (very good ratio, slower than

Hello there, I've had to set up some tools to convert cue+flac tuples to mp3 files and split albums flacs into songs flacs. Formerly on CentOS 6, I think I had shntools and cuetools from the nux-dextop repo (not sure about shntools). Anyway, here on CentOS 7 I couldn't find any of them in repositories, so I did `rpmbuild --rebuild` from: - cuetools-1.4.0-0.6.svn305.el6.nux.src.rpm -

Josh Coalson wrote: > --- Eric Sandeen <sandeen@sandeen.net> wrote: > >>1) how to generate a cue sheet to store in the flac file (on linux?) >> I've seen cddb2cue, is this a decent way? or cdrdao can generate >> a toc file, then convert that to a cue sheet.... > > > I think whatever provides cdrdao also provides toc2cue which > will convert.

Janne Hyv?rinen wrote: >> Can you share samples? > > It's a 470 MB copyrighted music album. I could but I don't think it's legal. How about sharing the album name (if it's popular enough)? (but then it would be good to post its CUETools verification log if the album has multiple pressings with different offsets...)

just want to run some OpenCL software in Wine... but found this blog: http://www.streamcomputing.eu/blog/2011-01-21/opencl-under-wine/ apps like: http://gpuimpulsereverb.de/ Flaccl http://www.hydrogenaudio.org/forums/index.php?showtopic=64628&st=275#entry767843 installed dev drivers 270 and latest 280 drivers for linux../nvidia installed Intel OpenCL1.1 sdk OpenCL CPU works...

On 13-03-13 10:49, Marko Uibo wrote: > I plan to test my ~20 GB flac collection how big difference flake -12 > gives me. But I still use reference implementation for my main collection. If I remember correctly gains were less then 0,5%, which for 20GB will be 100MB, not enough to get even one extra album in. If you like the idea of that little extra gain while sticking with FLAC (for

On 14 March 2016 at 09:02, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > commit a9f84425cfd5d1dbfb564730ca80d0b588cb4f24 > Author: Erik de Castro Lopo <erikd at mega-nerd.com> > Date: Mon Mar 14 18:14:31 2016 +1100 > > libFLAC/cpu.c: Use `sigemptyset` instead of `__sigemptyset` > > The former is POSIX while the later is a GNU

there is no work on the reference tools because it's not very portable (way less than the current asm optimizations). the third party implementations are good enough I think. --- On Fri, 1/1/10, Sumit Gupta <sumitg at gmail.com> wrote: Is anyone on this mailing list working on enabling FLAC using GPUs? There is CUDA (GPU) accelerated FLAC encoder available now

WARNING: This is not compatible with the previous lz4 patchset. If you''re using experimental compression that isn''t in mainline kernels, be prepared to backup and restore or decompress before upgrading, and have backups in case it eats data (which appears not to be a problem any more, but has been during development). These patches add lz4 and lz4hc compression

On Wed, Oct 7, 2020 at 3:43 AM Marvin Scholz <epirat07 at gmail.com> wrote: > > Hi, please provide the contents of the config.log > > I can not reproduce your issue on my machine, --without-openssl > works fine here. > > Oh and next time please mention that its about libshout right > away :) https://gist.github.com/neheb/a26714035978d07a822985477524cd45 > > On 7

On a related note, are there any tools which can read the Index information from a CD and preserve these in some file for later recreation? The actual TOC on a CD has very little information: just the Absolute Start Time of each Track. Is there any documentation of the "TOC" file format that is commonly used? I do not recall coming across anything. Obviously, I am also

Hello, When I look at email files on my server (mdbox format), they contain random LZ4 stuff. I have now changed the compression to gzip and new mails look cleaner. But older ones have problems. A mail file looks like this: 2 M1e C5655b6a8 ^A^BN 00000000000006F4 Dovecot-LZ4^M*<9B><C5>^@^A^@^@^@^@^F<DD><FF><83>Return-path: <nobody at

On Sun, May 10, 2015 at 08:16:54PM -0400, Darik Horn wrote: > > LZ4 is supposed > > to be a very fast compression algorithm, especially when it comes to > > decompression. I did a quick benchmark with zlib, LZO and LZ4. Now, > > there are many benchmarks you can find online, but most of them deal > > with compressing large files. Tinc on the other hand has to

On Sun, May 10, 2015 at 7:17 PM, Guus Sliepen <guus at tinc-vpn.org> wrote: > > Darik Horn sent a pull request adding support for LZ4. The PR is: * https://github.com/gsliepen/tinc/pull/78 > LZ4 is supposed > to be a very fast compression algorithm, especially when it comes to > decompression. I did a quick benchmark with zlib, LZO and LZ4. Now, > there are many

Hello, Darik Horn sent a pull request adding support for LZ4. LZ4 is supposed to be a very fast compression algorithm, especially when it comes to decompression. I did a quick benchmark with zlib, LZO and LZ4. Now, there are many benchmarks you can find online, but most of them deal with compressing large files. Tinc on the other hand has to compress small packets individually. So I did the

https://bugzilla.mindrot.org/show_bug.cgi?id=2888 Bug ID: 2888 Summary: Consider adding other compression schemes (lz4, zstd) Product: Portable OpenSSH Version: 7.7p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: Miscellaneous Assignee:

Hello Teemu, the version of my lz4 library is the most recent lz4-1.7.5, and "dovecot -n" output is as follows: # 2.2.30.1 (eebd877): /raid/data/module/Dovecot/sys/etc/dovecot/dovecot.conf # OS: Linux 2.6.33N7700 i686 auth_debug = yes auth_debug_passwords = yes auth_verbose = yes auth_verbose_passwords = sha1 info_log_path = /raid/data/module/Dovecot/sys/var/log/dovecot-info.log

Hi there ! I?m using dovecot 2.3.10 (manually compiled on Centos 8 x86_64 - fully updated), XFS filesystem, with mdbox and a separated compressed attachment directory: mail_attachment_fs = sis compress:lz4:6:posix mail_attachment_hash = %{sha256} mail_attachment_dir = /ATTACHMENTS I'm using dovecot LDA (for mail delivery). Everything works fine with the delivery and compression. The

I am running XEN on CentOS Linux release 7.8.2003 I have a Debian 7, and two Gentoo DomU Guests running fine. I am trying to get an Ubuntu 20.04 DomU Guest running but I get this error when trying to run the netboot kernel image xc_dom_probe_bzimage_kernel unable to LZ4 decompress kernel I understand that CentOS Xen does not support LZ4 decompression. Is there a workaround for this?

On 05.06.2017 11:02, awl1 wrote: > Resending - any ideas why I might get "IMAP session state is inconsistent" whenever emtyping the trash in Thunderbird? > > Thanks, > Andreas > > > Am 31.05.2017 um 00:02 schrieb awl1: >> All, >> >> having successfully compiled and set up Dovecot 2.2.29.1 on my Thecus NAS as a newbie without any further hassle,