similar to: Looking for users of --keep-foreign-metadata

Hello, I'm attempting to convert fairly large WAV files (90 - 800 MB each) using flac but the files do not work after the encoding. (The play fine in wav format) Command I'm using: flac --verify -8 file.wav Attempting to run the file with either flac123 or the default player for Ubuntu (Movie Player?) results in the extremely terse messages: Default Player: "An Error Occurred:

Thank you for the reply! I know that my system can play flac files, I've played others I've managed to convert using both of those programs. I'm only running into difficulty when it comes to these large WAV files. By "Does not work" I mean that they do not play, and instead I receive the errors I mentioned in my original post. I wasn't actually intending to use

Hi, I am attempting to use flac to encode 96k/24-bit broadcast wav (BWF) files. BWFs are wav files with some extra meta-data chunks, and is the favoured archival format for many institutions around the world. These files are encoded successfully by flac, however the resulting flac file is not playable on all flac players - it plays successfully in foobar2000 but is silent in winamp, and when

Dear all, I've converted a wav file to flac but during the process three wrnings were casted. One of them I recall, it said that a BEXT chunk is unrecognized and thus ignored. Wouldn't it be posible to keep the unrecognized information as is when decoding the file? In general the extra chunks are located before or after the audio content, and represents a tiny part of the whole

Are you sure they didn't change the default encoding level ? I would include some example timings to give a better idea of what "significantly slower" is Wonder if you see same for 44/16 files? > On Jul 25, 2014, at 2:29 AM, Martijn van Beurden <mvanb1 at gmail.com> wrote: > > Hi, > > You might want to report this to the flac-dev mailinglist instead of the

Not sure if this belongs here or in flac-dev. I am subscribed to both, so flop it over if fits better over there. Looking at the Changelog for FLAC 1.2.1 (17-Sep-2007), it says: "With the new --keep-foreign-metadata in flac, non-audio RIFF and AIFF chunks can be stored in FLAC files and recreated when decoding." Where can I find more detail on what is a

Please cc: the results from dev list back here though I would run some tests on a diff platform but don't have access to my PC for a few weeks Would also be interesting to see what decoding stats you get > On Jul 25, 2014, at 7:38 AM, Scott Brown <scottcbrown at gmail.com> wrote: > > I will post to the dev list, sorry about that. > > To give an idea, though, at flac

Hello, I'm on a Mac and I'm noticing that encoding via the flac command line is significantly slower with version 1.3.0 than 1.2.1. I'm encoding a 24/96 file to flac, both from wav and aiff and both formats are showing the same speed decrease when using 1.3.0. Also, 1.2.1 will not encode an aiff-c file, but 1.3.0 will. Is this change documented anywhere? Thanks, Scott --------------

I need uncorrupted metadata, as I use data in Base64 encoding in a long text tag for my music synchronized light show. Implemented now in .mp3 ID3 tags, I hope to extend to FLAC, but that only works if metadata is kept exactly in its original content. Scott Burkhart Scott Burkhart Effects, LLC http://www.scotteffx.com/ scott at scotteffx.com https://www.linkedin.com/in/scotteffx 1-925-202-8852

Isn't the FLAC encoder 'tuned' for the compression of audio data at common sample rates anyway? Does it make sense to use FLAC to compress arbitrary analog data at very high sample rates as opposed to other general purpose compression algorithms? Tor Am 25.06.2020 um 14:49 schrieb Martijn van Beurden: > Op di 2 jun. 2020 om 05:59 schreef Con Kolivas <kernel at kolivas.org

This patch to opus-tools adds optional support to WavPack lossless format as input to opusenc. Like support to FLAC, it depends on an external library, libwavpack, and may be disabled on configure. Lucas Clemente Vella (1): Reading input from WavPack files. Makefile.am | 7 +- configure.ac | 37 ++++++++ src/audio-in.c | 71 ++++++++------- src/opusenc.c | 19 +++- src/opusenc.h

Op do 25 jun. 2020 om 16:02 schreef Con Kolivas <kernel at kolivas.org>: > The idea is to actually use it for playback, not just storage, and > nothing else has the nice asymmetrical fast decompression with such > effective compression (wavpack supports 705/768 but is woefully slow > on decompression and poorly supported). Mostly the sample rates would > be multiples of the

On Jan 12, 2013, at 14:28, Martijn van Beurden wrote: > On 12-01-13 22:46, Brian Willoughby wrote: >> I would suggest that everyone keep in mind the vast installed base of >> hardware FLAC recorders and players, and not senselessly make them >> obsolete without extremely compelling reasons. > > This can be done for the same reason the change from 1.1 to 1.2 > added

"Didier Dambrin" <didid at skynet.be> wrote: ... > I like FLAC on the paper because of its metadata preservation, in that riff > tag, which is critical for my needs. Try using WavPack, http://www.wavpack.com/ This can losslessly compress 32-bit floating point WAVE-EX files, and faithfully preserves every chunk (which FLAC does not do). It is also free. Regards, Martin --

Op zo 20 okt 2024 om 03:08 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>: > > I'm not sure what else there could be in "STREAMINFO_EXT" except for > total samples and sample rate, but maybe there is some other use for (at > least partially) backward-compatible flac extensions. > > Adding that to ffmpeg would also be rather simple. > As with any such

Op do 3 nov. 2022 om 19:39 schreef Federico Miyara <fmiyara at fceia.unr.edu.ar>: > > > Martijn, > > Currently FLAC already stores and restores most kinds of metadata corruption without problems, so in most cases the conversion is already bit-accurate. However, there are some kinds of corruption it cannot handle. These are the kinds of corruption that invalidate your

Can you please wrap the setvbuf in _WIN32 IFDEFs too? Currently memory usage of FLAC decoding is about 1MB, so this patch is increasing memory usage tenfold, also for platforms that do not need this. It is a non-problem on my system anyway. Op 26-09-14 om 10:36 schreef Janne Hyv?rinen: > I made some changes to the previous patch. I don't know why I > originally didn't put the

On Jan 12, 2013, at 05:30, Martijn van Beurden wrote: > On 12-01-13 08:23, pyth.flac-dev.5.pyt at spamgourmet.com wrote: >> I seem to recall that changes in the second number indicated a minor >> change in the *format* of the file itself (for example, 1.1.x to >> 1.2.x >> introduced a new rice coding option used for 24-bit files). > > Well, the only change in

Hi Martijn Thank you for the link. Could those old installers be taken down or at least moved to a 'old' folder ? I'm new to this, so I am a good example of how a new user works. I use google, or I visit the homepage, and then I download and install. As that installer version doesn't work at all, it cant convert WAV files, I suggest to delete it completely. Regards, Jonny On

Hi, This patch improves compression a very tiny bit on average, but up to 0.1 percentage point for classical music. I haven't found any tracks that show worsening compression with this patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Improve-LPC-order-guess.patch Type: text/x-patch Size: 0 bytes Desc: not available Url :