similar to: flac-dev Digest, Vol 103, Issue 7

Hi all, Thanks in advance for your help, and sorry for the slow reply. I've created a small OS X example project <https://drive.google.com/file/d/0B8vFUUth7NpvRFI0MmI2bVJNNEU/view?usp=sharing> that reproduces the issue. (I've run into the size limit for emails on this list so I've put it on Google Drive.) The program just initializes a libFLAC++ stream decoder for a given file

Hi, Thank you both for your replies. I will try to put together a repro case when I get a chance. In our case, we are recording audio directly into FLAC files, so they can end up with very short durations. Since I sent my first email, I have also seen this reproduce with longer files. Thanks, Luke On Mon, Nov 21, 2016 at 3:07 PM, Federico Miyara <fmiyara at fceia.unr.edu.ar> wrote:

-------- Forwarded Message -------- Subject: Re: [flac-dev] Flac multi channel Date: Wed, 25 Jan 2017 15:55:14 -0300 From: Federico Miyara <fmiyara at fceia.unr.edu.ar> To: Tor-Einar Jarnbjo <tor-einar at jarnbjo.name> Besides the fact that many multichannel signals largely exceed 8 channels, there are examples of signal packaging with many channels which are actually

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

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

Dear Friends, I am new to this mailing list. I am with the National University of Rosario, Argentina, and I am writing a book on software-based acoustical measurements, which includes a chapter on FLAC for archival and streaming purposes from an remote embedded system including a sensor. I would like to ask why the seekpoint information in the seek table metadata block reserves 64 bit for

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 > considerations. For example, when a chunk length is incorrect, the > location and length

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

I was wondering when it would be useful to compress very short audio files. The answer may be when there are lots of files, for instance in the case of sound fonts, or a large collection of transients. Probably it would be better to compress the whole collection as a single large file obtained by juxtaposing the short clips, with cues or marks to separate the original files. May be this

Dear All, I've sent yesterday this issue, but as it contained two screenshots, I'm not sure if it reached the list. I post it again with some updates. 1) I had encoded a WAV file three years ago. Examining the FLAC file with an HEX/text viewer, i find at the beginning, after some headers, it declares reference libFLAC 1.3.1 20141125. However, I'm pretty sure I didn't use that

Federico Miyara wrote: > I would like to ask why the seekpoint information in the seek table > metadata block reserves 64 bit for the number of first sample in > target frame and for the offset of the first byte of target frame. > > It seems to me a lot, since 2^64 = 1.84e+19, i.e., far more samples > and bytes than can be expected in any file... ever. Fast reverse to the year

There are several links to Windows compiles in the Hydrogenaudio thread for FLAC 1.3.0 at http://www.hydrogenaudio.org/forums/index.php?showtopic=101082 . On Unices or Linuxes building from git should be straightforward enough, or you wait until the distributions/package maintainers catch up. Also, congratulations to the whole development team for reinvigorating FLAC! Christoph On

I posted Mac binaries a few weeks ago but nobody did anything with them, or even acknowledged them. Here is a DMG with a .pkg installer for Flac 1.3.0 https://dl.dropboxusercontent.com/u/52358991/FLACInstaller1.3.0.dmg On Wed, Jun 26, 2013 at 3:00 PM, <flac-dev-request at xiph.org> wrote: > Send flac-dev mailing list submissions to > flac-dev at xiph.org > > To

Dear Ulrich, Thanks for your answer. >Well, today 4 GiB is about half an hour of 8-channel, 96 kHz, 24-bit >uncompressed audio, or about 0.9 % of the capacity of a modest 2 TB >HDD. Not much, in other words, and who hasn't cursed yet at artificial >4 GiB (or even 2 GiB) limitations? So I wouldn't be too sure about the >"ever", even though it does seem very far

Hi all, I'm writing to you becuase I have compiled PAM in SCO (now Caldera) Openserver 5.0.x, and when I tried to use SSH with PAM enabled, y realized that OpenSSH depends on the user to exist en the /etc/passwd, and /etc/shadow databases, or equivalent ones (it uses getpw...() functions to determine validity of the user). In Linux, the simlpe solution is to use nsswitch, but it seems to hard

Dear Stefan, In the paper "Improved Forward-Adaptive Prediction for MPEG-4 Audio Lossless Coding", a non-linear compander is applied to the parcor coefficients prior to quantization. This compander is designed in order to minimize quantization error, especially for magnitudes close to unity. If you determine the typical distribution of magnitudes of the LPC coefficients, you could

On 25 Nov 2014, at 08:43, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Hi all, > > As people may have seen there's a pre-release here: > > http://downloads.xiph.org/releases/flac/beta/ > > Specifically: > > flac-1.3.1pre1.tar.xz : The source code > flac-1.3.1pre1-win.zip : Windows 32 and 64 bit binaries > > Please test. >

Federico Miyara wrote: ... > The file format allows some unused fields for future use, such as the > padding block. It could include a flag to indicate a change in the > format adding one more streaminfo byte which would allow up to 256 > channels (actually, 256 + 8), or it could trigger a new byte when 11111111. > > There is also an invalid block identifier (127) which could be

Federico Miyara wrote: > Thanks for your answer. > > >Well, today 4 GiB is about half an hour of 8-channel, 96 kHz, 24-bit > >uncompressed audio, or about 0.9 % of the capacity of a modest 2 TB > >HDD. Not much, in other words, and who hasn't cursed yet at artificial > >4 GiB (or even 2 GiB) limitations? So I wouldn't be too sure about the >

Federico Miyara wrote: > > Dear all, > > I have a wav file that when I try to encode with the FLAC Frontend, I > get "ERROR: unsupported format type 3". WAV format 3 is 32 bit IEEE float which is not supported by FLAC. > When I open it with an audio editor I find it is 44100 / 32 bit. 32 bit *floating point* values. WAV files can also contain 32 bit (integer)