search for: subchunk

...sy to explain me, a > > user? > > are you using windows or unix? on unix you can do something like: > > od -c file.wav | head -20 > > which will show you the first 100 or so characters. any non > printable ones will be in octal (like \003 for ctrl-c). compare the > subchunks you find against the wav format: > > http://www.borg.com/~jglatt/tech/wave.htm > > if it has a 'list' 'plst' 'cue ' 'labl' 'note' or any subchunk that > is not 'data' then flac will not parse it. ok, I found a "pad" subchun...

So let me get this straight... I can put a CD in my computer and copy it to my hard drive as a wav files. Then by using FLAC to "compress" said wavs into .flac files. Resulting in approx. half the file size. Then later I can convert the FLAC files back to wav and the end up with the EXACT wav file I had before ? If this is the case, then great, but can you really cut out half the

...> not sure about this one. > >> i nabbed the binaries for 1.0.3 and, each time i use flac to compress >> something in tests, i receive this error when it is done compressing a file: >> >> "WARNING: skipping unknown sub-chunk 'LIST'" > > list subchunks in wave files are not stored. you probably don't need them > anyway, they're metadata not audio. thanks, josh. i posted without including some obviously useful information... os: osx 10.2.1 fink: latest cvs build apple dev tools: latest (july w/ august patch) i attempted to build f...

Two wavs I tried to encode tonight got errors near their ends, saying something like "skipped unknown sub-chunk 'LIST'." These occurred at 97% into one file and 98% into the other. If I hadn't brought the DOS command window to the foreground and hadn't been at the monitor watching before these warnings were scrolled away by the displays from work on other files in the

on this topic... i configured and built 1.0.4 in osx 10.2. seemed to build fine, but each time i attemped to use the newly compiled flac binary I received this error "bus error" i nabbed the binaries for 1.0.3 and, each time i use flac to compress something in tests, i receive this error when it is done compressing a file: "WARNING: skipping unknown sub-chunk

...t; All created binaries are successfully run. > Al tests from ./usr/klibc/tests are successfully run. > > > Any suggestions are welcome. > I could provide any additional info if needed. > Please don't submit a single monolithic patch. Instead break it down into reasonable subchunks, each with a description. This is the same procedure as for submitting patches to the Linux kernel. -hpa

Hello, I have found that there are some WAV files which have a "fmt" chunk size greater then 16 bytes (length indicator greater then 16). The patch is attached. What is the normal method for submiting patches? Regards, Chris Wolf <HR NOSHADE> <UL> <LI>application/octet-stream attachment: audio.c.patch </UL> -------------- next part -------------- A non-text

When you maximize the window, the position of the Fingerprint button doesn't adjust; the Help function still scrolls the first two screenfuls together without a break, so that the first screenful is impossible to read; not sure how, but the first time I tried it, it locked up and couldn't close (needed a three-finger salute). This is under WindowsME on a vintage 1998 266MHz Pentium II.

...ry Hoath <kerry@gotss.net> wrote: > There is no standard for wav64 and a .wav in its standard form can only hold > 2gb of data. In this case the WAV files were less than 2 GB. > libsndfile can handle larger .wav files and so can other audio applications > but usually nonstandard subchunk data means that the wav reader in flac > can't understand the file. This was simply a recording which was terminated before completion so the final size of the WAV was not written in the header. That is not an uncommon event during content creation. When reading a WAV, many programs check...

...naries for 1.0.3 and, each time i use flac to compress >>>> something in tests, i receive this error when it is done compressing a >>>> file: >>>> >>>> "WARNING: skipping unknown sub-chunk 'LIST'" >>>> >>> list subchunks in wave files are not stored. you probably don't need them >>> anyway, they're metadata not audio. >>> >> thanks, josh. >> >> i posted without including some obviously useful information... >> >> os: osx 10.2.1 >> fink: latest cvs b...

...'s a summary: * both encoder and decoder are significantly faster * flac now has gzip-like command-line usage (should be more intuitive) * the -# options have been tweaked for efficiency; -5 is the new default * flac now autodetects WAVE input * flac now ignores (with warning) unsupported WAVE subchunks * new -o and --delete-input-file options * XMMS plugin tweaked so that visualizations should not be so slow * new SEEKTABLE metadata block for storing seek points (speeds up seeking) http://flac.sourceforge.net/news.html This is very likely the last beta as I am happy enough with the performan...

I know this is probably a really stupid question, but why is FLAC's MD5 checksum different than the MD5 checksum of the original (input) .wav? I was under the impression that since each FLAC file contains metadata that can be changed without changing the audio (thus changing the MD5 checksum of that FLAC file) that the checksum of the original .wav file would instead be used. If that's

...; >> i nabbed the binaries for 1.0.3 and, each time i use flac to > compress > >> something in tests, i receive this error when it is done > compressing a file: > >> > >> "WARNING: skipping unknown sub-chunk 'LIST'" > > > > list subchunks in wave files are not stored. you probably don't > need them > > anyway, they're metadata not audio. > > thanks, josh. > > i posted without including some obviously useful information... > > os: osx 10.2.1 > fink: latest cvs build > apple dev tools: lat...

...om there on is identical. It seems to me that what appear to be > length fields in the header is adjusted appropriately. > > I suspect that this is not a problem, but it makes using 'cmp' to prove > that FLAC works for me difficult. the difference is probably a 18-byte fmt subchunk in the original vs. a 16-byte in the decoded WAV. flac isn't a WAV file compressor, it does not store everything about a WAV file so it can be exactly reproduced, it only stores the audio, so cmp is not the right way to prove that flac is working. a better way is to compare the MD5 sum in the...

...vin [hpa at zytor.com] > Sent: Wednesday, August 27, 2014 5:34 AM > To: Dejan Latinovic; YunQiang Su; klibc at zytor.com; maximilian attems > Subject: Re: [klibc] [PATCH] add mips64 support > Please don't submit a single monolithic patch. Instead break it down > into reasonable subchunks, each with a description. This is the same > procedure as for submitting patches to the Linux kernel. Thanks, Here are changes that adds mips64 support for klibc, separated into 3 patches. Any additional suggestions are welcome. -------------- next part -------------- A non-text attachment...

On 03/11/2014 09:38 AM, H. Peter Anvin wrote: > On 03/10/2014 11:21 PM, YunQiang Su wrote: >> From: Dejan Latinovic <Dejan.Latinovic at imgtec.com> > > Description goes here? I think it would be helpful to break this up > into a few patches with descriptions. > >> + unsigned long __f20; >> + unsigned long __f21; >> + unsigned long __f22; >> +

Brian Willoughby wrote: > The ckSize field can be odd to represent the size of the valid data. > > However, the chunk itself must always be an even size. This requires a padding byte at the end of a chunk before the next chunk can begin, or before the end of file. The latter case is the one that most often occurs in buggy RIFF writing programs - the last chunk will have an odd ckSize and

Hi! I'm just now preparing the first, still very experimental (way pre-1.0) release of a new archival tool, similar to (and based on) zip/unzip, with the difference that the enhanced zip tool can store x86-based decompressor code fragments in archives along with the compressed data, which the unzip tool runs in an isolated user-mode virtual machine in order to extract the data. The main