Oops, I knew that looked too big. Neurones tired :-)
Pyt.
> Le 10 mai 2017 à 21:18, lvqcl a écrit :
>
> Pierre-Yves Thoulon wrote:
>
>> None, apart from the standard metadata block size limitation (2^24 bytes,
>> e.g. 4GB). Pretty big for any kind of album art...
&
None, apart from the standard metadata block size limitation (2^24 bytes, e.g.
4GB). Pretty big for any kind of album art...
Kind regards.
Pyt.
> Le 10 mai 2017 à 17:11, Scott Brown - scottcbr...@gmail.com
> a écrit :
>
> Is there any size limitation for album art?
>
> I have a user who s
On Sat, Sep 26, 2015 at 10:36 AM, Martijn van Beurden
wrote:
> > * This is nuts. 24 bits has a dynamic range of ~140dB which is roughly
> >the difference between a quiet whisper in a quiet room, to the sound
> >of a jet engine at 10 meters. Surely that is enough?
>
> Yes, this is nuts. Fi
Looks good to me, even though I'm not the most active on this list and
others might have a better say...
Kind regards,
Pierre-Yves Thoulon.
http://mjuware.com (home of FlacNetLib)
--
Pierre-Yves Thoulon
+33 (0)6 33 39 75 76
On Tue, Aug 18, 2015 at 7:38 PM, Tessa Fallon
wrote:
> Dear
> Janne Hyvärinen wrote:
>
>>> Can you share samples?
>>
>> It's a 470 MB copyrighted music album. I could but I don't think it's legal.
For private use it is, at least in some countries (France for sure).
Pyt.
___
flac-dev mailing list
flac-dev@xi
Really sorry about this, www.mjuware.com is still unstable (thanks Jan for
pointing this out). Please continue using the mirror at
http://www2.mjuware.com for now. The situation should be fixed within a day
or so (time for the information to propagate across DNSes around the
world...).
And sorry f
Referring to my message of a couple of days ago, www.mjuware.com is back
online. Sorry for the inconvenience.
Pyt.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Hello, everybody,
Just in case you hit the wall, www.mjuware.com (home of FlacNetLib,
FlacInfo and RipFlac) is temporarily out due to a change in domain name
registration. Until this is fixed, the site is available at
http://www2.mjuware.com
Sorry for the inconvenience,
Pyt.
_
the limitation (which not only applies
to METADATA_BLOCK_PICTURE but all metadata blocks.
Pyt.
--
Pierre-Yves Thoulon
+33 (0)6 33 39 75 76
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Speaking of better compression, I've been using the following options on
the command line for ages. I'm not sure what they actually do (stole the
recipe from a thread on this mailing list, if I remember right), but they
seem to improve the compression ratio over just using --best (by 0.3 to
0.5% ty
I second Brian's position on the matter, for what it's worth...
Pyt.
On Sun, Jan 13, 2013 at 12:46 AM, Brian Willoughby wrote:
>
> On Jan 12, 2013, at 14:28, Martijn van Beurden wrote:
> > On 12-01-13 22:46, Brian Willoughby wrote:
> >> I would suggest that everyone keep in mind the vast inst
I've implemented a full decoder in c# from the textual description and minimal
access to the reference code. I think I had to do some research on Rice coding,
though.
The code is available at http://www.mjuware.com if that's of any help.
Pyt.
On 6 oct. 2012, at 15:33, Tor-Einar Jarnbjo wro
decide which is the best compression method for a
set of samples, and I'm not sure that it would give twice the same results
for encoding the same file, although those results would be statistically
similar...
--
Pierre-Yves Thoulon
On Wed, Mar 23, 2011 at 22:33, Brian Willoughby - bri...@soun
Is this achieved by adding a cuesheet in the VORBIS_COMMENT block, using a
CUESHEET key ? Some players can interpret this, as does foobar2000. That's
what I used for my own collection. All FLAC files are exact copies of the
original CD, properly indexed. I've written a couple of utilities to ease
t
14 matches
Mail list logo
