[flac-dev] Question about FLAC encoder behaviour

Hello all! I have a question about the FLAC's reference implementation encoder. So I have the following use cases: I have tested both flac 1.3.2 and flac 1.4.3 on reencoding existing .flac files with the -f option. There are cases in which I try to reencode .flac files which are compressed

Re: [flac-dev] Question

The frontend has no knowledge of the version being used. The command window that pops up displays the information directly from the encoder so, the version you have downloaded that claims to be 1.3.2 is displaying 1.3.0 when it is executed. This may simply be that the character string in the

Re: [flac-dev] Question

So the frontend doesn't detect the version of the real codec but remains freezed informing a built-in version number 1.3.0? Regards, Federico Miyara On 29/07/2021 15:07, Martijn van Beurden wrote: 1) I'm using a portable version of frontend 2.1 for Windows, I've downloaded version 1.3.2

Re: [flac-dev] Question

> 1) I'm using a portable version of frontend 2.1 for Windows, I've downloaded > version 1.3.2 of the main program, I place it in the right directory but the > front end keeps saying that the version is 1.3.0. > 2) I could't find an executable version of the command line program 1.3.3. > Does

Re: [flac-dev] Question

Martijn, Thanks for the information. Regards, Federico Miyara On 27/07/2021 08:59, Martijn van Beurden wrote: Op di 27 jul. 2021 om 07:49 schreef Federico Miyara mailto:fmiy...@fceia.unr.edu.ar>>: Is there a way to retrieve a specific range of samples from a .flac file? Yes,

Re: [flac-dev] Question

Op di 27 jul. 2021 om 07:49 schreef Federico Miyara < fmiy...@fceia.unr.edu.ar>: > > Is there a way to retrieve a specific range of samples from a .flac file? > Yes, there is. This is possible with the flac command line tool, using options --skip and --until. Please take a look at the

[flac-dev] Question

Dear All, Is there a way to retrieve a specific range of samples from a .flac file? For instance, saving them to a wav file. Thanks, Federico Miyara -- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus

Re: [flac-dev] Question: MSVS 2005/2008 support?

lvqcl wrote: > Are there any developers that want to use libFLAC in their programs > and still use Visual Studio 2005 or 2008 ? 2008 is 10 years ago and the other is older. The don't work now (due to ogg) and they cannot be fixed. These should be removed. Erik --

Re: [flac-dev] Question: MSVS 2005/2008 support?

On Wed, May 2, 2018 at 5:25 PM, Stéphane Damo wrote: > I don't like the decision to remove the old VS project files, in my opinion > it's better to keep them, marked "not updated anymore". But it means that they eventually will become unusable. Besides, files that are

Re: [flac-dev] Question: MSVS 2005/2008 support?

I don't like the decision to remove the old VS project files, in my opinion it's better to keep them, marked "not updated anymore". I personnally use VS2013, and the reason I don't want to upgrade is the fact that VS2017 requires online registration to work. I'm pretty sure some users also have

Re: [flac-dev] question about src/test_seeking.c - seek_barrage()

lvqcl wrote: > seek_barrage() has variable n of type long int (which is 32bit usually). Thats true on Windows, but on both 32 and 64 bit linux sizeof (long int) is 8. > Then we see something like > > n = (long int)total_samples; > > So, why n has type long int, and not FLAC__int64 or some

[flac-dev] question about src/test_seeking.c - seek_barrage()

seek_barrage() has variable n of type long int (which is 32bit usually). Then we see something like n = (long int)total_samples; So, why n has type long int, and not FLAC__int64 or some other 64-bit type? ___ flac-dev mailing list flac-dev@xiph.org

Re: [flac-dev] question about src/test_seeking.c - seek_barrage()

Agreed. Although there wasn't a universal standard when FLAC was started, it sure seems like int64_t and related types are available on all systems these days. Either FLAC__intXX or intXX_t are better than the old types, like byte, word, dword, quadword, or whatever. Brian On Jan 31, 2016,

Re: [flac-dev] question about 0bea5fb commit

lvqcl wrote: > So I wonder - does it makes sense to change this type too? > The patch is attached. I updated the tests to test unsigned as well as signed and then applied your patch. Cheers, Erik -- -- Erik de Castro Lopo

[flac-dev] question about 0bea5fb commit

The patch http://git.xiph.org/?p=flac.git;a=commitdiff;h=0bea5fb96436588b4e78c5be79bf174b9be7a202 changes the type of t value from FLAC__int32 to uint32_t, but only for 24-bit signed input samples. 24-bit *un*signed input still uses FLAC__int32 t. So I wonder - does it makes sense to change

Re: [flac-dev] question about 0bea5fb commit

lvqcl wrote: > The patch > http://git.xiph.org/?p=flac.git;a=commitdiff;h=0bea5fb96436588b4e78c5be79bf174b9be7a202 > changes the type of t value from FLAC__int32 to uint32_t, > but only for 24-bit signed input samples. 24-bit *un*signed > input still uses FLAC__int32 t. These UB fixes were

Re: [flac-dev] question about 0bea5fb commit

Erik de Castro Lopo wrote: > These UB fixes were driven purely by UBSan warnings generated while running > the test suite. The fact that no warning was gneerated by 24 bit unsigned > input suggests that the test suite doesn't cover 24 bit unsigned input. Yes, I can see only --sign=signed option

Re: [flac-dev] Question from Argentina

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

Re: [flac-dev] Question from Argentina

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?

Re: [flac-dev] Question from Argentina

Federico Miyara wrote: Fact is that FLAC is highly economical in items such as reserving 20 bits for sampling rate or 3 bits in the middle of the middle of a byte for number of channels (which are, in fact, currently too few for applications such as beamforming that use arrays of several

Re: [Flac-dev] question regarding compression %

--- Gordon Gidluck [EMAIL PROTECTED] wrote: Hi, For those of you who don't know, I now have an application on pocket pc using flac. Live2496 does realtime encoding while recording. Live2496 typically is used to record a digital source using the Core Sound PDAudio device. Links are now on the