search for: miyara

...flac-dev-owner at xiph.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of flac-dev digest..." > > Today's Topics: > > 1. Re: (no subject) (Erik de Castro Lopo) > 2. Question from Argentina (Federico Miyara) > > > ---------- Forwarded message ---------- > From: Erik de Castro Lopo <mle+la at mega-nerd.com> > To: flac-dev at xiph.org > Cc: > Date: Wed, 12 Jun 2013 18:52:38 +1000 > Subject: Re: [flac-dev] (no subject) > Janne Hyv?rinen wrote: > > > On 10.6.2013...

...adata 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. Thank you in advance. Best regards, Federico Miyara

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...

...9;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 file, so it oould affect only very slightly the compression ratio attained. Regards, Federico Miyara -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20200429/b78908ca/attachment.html>

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 whe...

On 05-06-13 00:27, Erik de Castro Lopo wrote: > Martijn van Beurden wrote: >> Considering flac.sourceforge.net, is this ever going to be updated? In >> case it should be redirected, I checked on my own sourceforge project >> webpage, adding the following two lines to .htaccess should redirect >> traffic to any resource on flac.sourceforge.net to xiph.org/flac >>

...t sample resolution and say... about 100 channels (but by the very definition of a sample count one should consider one sample per frame, even if it has 100 subframes) one would have room for a 7616 year file! It seems a bet for a long life for FLAC --and for humankind! Best regards, Federico Miyara

...ined. Once located the optimum alignment, the FLAC algorithm would provide bit-for-bit accuracy and maximum compression, even in the absence of format-awareness. It would take a bit more time to encode and could generate its internal header for direct playback compatibility. Regards, Federico Miyara -- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20221103/112ec5f5/attachment.htm>

...rsion of the metadata, in contrast to the 1.3.1. I guess now the info is zipped or so. Finally, with all the other files I had no problem. I don't think this is relevant, but just in case, the original encoding was made on Windows 7 and now I'm working on Windows 10. Regards, Federico Miyara Images included in the first post (not sure whether they reach the list, I can post them individually at request): Beginning of the file viewed as HEX Comparison of both files. Right: original WAV file, Left: Decoded WAV file from 1.3.1 FLAC file -- Este correo electr?nico ha sido analiz...

Dear all, I have a wav file that when I try to encode with the FLAC Frontend, I get "ERROR: unsupported format type 3". When I open it with an audio editor I find it is 44100 / 32 bit. I requantized it to 16 bit using the default dither and then compressed it with FLAC to get a 61 Mbyte file (the original was about 347 Mbyte). Obviously, this altered somewhat the quality, although

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

...ybody for their answer. > > This is quite unfortunate for me, but hey, that's life. > > I will probably end up doing some multi mono bundle similar to what Protools did back in the days with its .L .R files > > Le 26/01/2017 à 18:58, Martin Leese a écrit : >> 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...

...hance. > > 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: > >> >> 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. Probabl...

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 sample...

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 (o...

lvqcl wrote: > Oops. It seems that vsnprintf_s isn't always available on MinGW platform: > MinGW declares this function only if MINGW_HAS_SECURE_API macro is defined. > That's because WinXP version of msvcrt.dll doesn't contain secure functions > like vsnprintf_s. I thought Micorsoft had recently stopped supporting WinXP. If Micorsoft has stopped supporting it I see no

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...

...ry 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: > > 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...

-------- 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 non-simultaneous, independent signals, for insta...

Thanks everybody for their answer. This is quite unfortunate for me, but hey, that's life. I will probably end up doing some multi mono bundle similar to what Protools did back in the days with its .L .R files ++ Le 26/01/2017 à 18:58, Martin Leese a écrit : > 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 t...