2013/2/10 Erik de Castro Lopo :
> Johnny Rosenberg wrote:
>
>> And of course you won't waste your time replying outside this mailing list?
>> Is there a libsndfile mailing list?
>> Hm… yet another stupid question, of course. If there is, you wouldn't
>> want me to know about it, right? :P
>
> h
Johnny Rosenberg wrote:
> And of course you won't waste your time replying outside this mailing list?
> Is there a libsndfile mailing list?
> Hm… yet another stupid question, of course. If there is, you wouldn't
> want me to know about it, right? :P
http://lmgtfy.com/?q=libsndfile+mailing+lis
2013/2/10 Erik de Castro Lopo :
> Johnny Rosenberg wrote:
>
>> Anyway, if I'm allowed to ask a libsndfile question here,
>
> Sorry, but no, this list is for FLAC related discussion.
And of course you won't waste your time replying outside this mailing list?
Is there a libsndfile mailing list?
Hm…
Johnny Rosenberg wrote:
> Anyway, if I'm allowed to ask a libsndfile question here,
Sorry, but no, this list is for FLAC related discussion.
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
_
Whatever enhancements occur for libFLAC, we certainly should not
create a situation where some flag gives different results for one
set of users versus another. Normalization of data should be separate
from conversion of data. libFLAC should only handle conversion of
data. If people want a
2013/2/9 Erik de Castro Lopo :
> Johnny Rosenberg wrote:
>
>> For example, when loading an audiofile with libsndfile, all the
>> samples are converted to floating point numbers,
>
> With libsndfile, converting to float is optional. You can just as
> easily read int or short.
>
>> which is what I wa
Johnny Rosenberg wrote:
> For example, when loading an audiofile with libsndfile, all the
> samples are converted to floating point numbers,
With libsndfile, converting to float is optional. You can just as
easily read int or short.
> which is what I want
> anyway, but the conversion is done by
On Sat, Feb 09, 2013 at 04:28:57AM -0800, bri...@sounds.wa.com wrote:
> Regardless of libsndfile's architecture and design, libFLAC should by
> no means duplicate the incorrect conversion. There especially should
> not be an asymmetrical set of conversion factors.
+1 to that!
--
-Dec.
---
2013/2/8 Erik de Castro Lopo :
> Collin wrote:
>
>> It turns out it was an error on my part; sorry for the trouble. I
>> misunderstood
>> the format libflac was expecting my samples in. I found the
>> wording in the
>> documentation very confusing.
>>
>> My audio file has 2 channels and 16-bit
2013/2/8 Erik de Castro Lopo :
> Collin wrote:
>
>> It turns out it was an error on my part; sorry for the trouble. I
>> misunderstood
>> the format libflac was expecting my samples in. I found the wording in the
>> documentation very confusing.
>>
>> My audio file has 2 channels and 16-bit sample
Collin wrote:
> It turns out it was an error on my part; sorry for the trouble. I
> misunderstood
> the format libflac was expecting my samples in. I found the wording in the
> documentation very confusing.
>
> My audio file has 2 channels and 16-bit samples, so I have to pull out each
> individ
Erik de Castro Lopo mega-nerd.com> writes:
>
> Collin wrote:
>
> > Has anyone encountered a similar problem, or are there any known issues that
> > could explain this?
>
> No known issues of this kind, but I would like to see a repeatable test
> case so I can investigate further.
>
> Cheers,
Are you calling
FLAC__stream_encoder_finish(encoder);
before you call
FLAC__stream_encoder_delete(encoder);
That would cause this issue.
-Ben Allison
> I'm using libflac on Windows to compress some audio samples. I'm building
> the
> library locally, using Visual Studio 2010. Each set of data is
On 07-02-13 23:07, Collin wrote:
> I'm using libflac on Windows to compress some audio samples. I'm building the
> library locally, using Visual Studio 2010. Each set of data is 2-5 MB and well
> formed PCM encoded data. I'm finding some very odd behavior.
One of the main strengths of FLAC is that
Collin wrote:
> Has anyone encountered a similar problem, or are there any known issues that
> could explain this?
No known issues of this kind, but I would like to see a repeatable test
case so I can investigate further.
Cheers,
Erik
--
-
Cristian Rodríguez wrote:
>> sample sets. Each set of samples returns this error at a different location
>> in
>> the stream, but always the same location for the same file.
>>
>> or has many bytes that are close to the original. The bad frame's data is
>> always
>> the same, no matter how many t
El 07/02/13 19:07, Collin escribió:
> I'm using libflac on Windows to compress some audio samples. I'm building the
> library locally, using Visual Studio 2010. Each set of data is 2-5 MB and well
> formed PCM encoded data. I'm finding some very odd behavior.
>
> If I enable verify on the encode st
I'm using libflac on Windows to compress some audio samples. I'm building the
library locally, using Visual Studio 2010. Each set of data is 2-5 MB and well
formed PCM encoded data. I'm finding some very odd behavior.
If I enable verify on the encode stream, I get a verify mismatch on most of my
s
18 matches
Mail list logo