search for: scottcbrown

Is there any size limitation for album art? I have a user who says adding large artwork (from a scanner) is corrupting the file metadata. I don't know if this is a flac limitation, a tag lib issue, or something I'm doing. Thanks, Scott -------------- next part -------------- An HTML attachment was scrubbed... URL:

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... 2^24 = 16777216, i.e. only 16 Megabytes. > Kind regards. > > Pyt. > > >> Le 10 mai 2017 à 17:11, Scott Brown - scottcbrown at gmail.com >> <flac-dev.pyt.8c0cc6600b.scottcbrown#gmail.com at ob.0sg.net> a écrit : >> >> Is there any size limitation for album art? >> >> I have a user who says adding large artwork (from a scanner) is >> corrupting the file metadata. I don't...

...the " Neon optimizations : ...................... yes" output. When I compile the official 1.4.2 source, there's nothing about Neon. Has this just been removed from the output, or is the official 1.4.2 missing something? Thanks, Scott On Mon, Sep 19, 2022 at 4:15?PM Scott Brown <scottcbrown at gmail.com> wrote: > Hi everyone, > > I'm back with the same issue as before: flac encoding on an M1 Max Macbook > pro is much slower on an arm build of 1.4.0 than it is running through > emulation on an x86_64 build. > > ./configure -enable-static -disable-shared CFL...

............ no Encoding flac level 8 for 1 file with 1.4.0 for x86_64 takes: 7.38 seconds The same file with the arm build from the settings above: 41.71 seconds This file is a 24 bit, 96khz wav file. Any idea what's causing this? Thanks, Scott On Sun, Jul 10, 2022 at 5:01 PM Scott Brown <scottcbrown at gmail.com> wrote: > Thank you very much, Robert. Setting the CXXFLAGS and LDFLAGS did indeed > solve my compilation issue. > > The resulting build now encodes this same fileset at level 8 in 1:46. > > so now we have: > > current code in git, intel build running throug...

Please cc: the results from dev list back here though I would run some tests on a diff platform but don't have access to my PC for a few weeks Would also be interesting to see what decoding stats you get > On Jul 25, 2014, at 7:38 AM, Scott Brown <scottcbrown at gmail.com> wrote: > > I will post to the dev list, sorry about that. > > To give an idea, though, at flac level 8: > > 24/96 wav file > 1.21: 61.05 seconds. ratio=0.690 > 1.3: 222.48 seconds. ratio=0.690 > > smaller 16/44.1 wav file > 1.21: 14.28 seconds....

...ct: Re: [flac-dev] slow on apple silicon? > Message-ID: <b97549ba-844d-cc21-752b-5889e35819bd at freac.org> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Am 08.07.2022 um 09:26 schrieb Martijn van Beurden: > > Op wo 6 jul. 2022 om 22:09 schreef Scott Brown <scottcbrown at gmail.com>: > > > > Same list of cputype errors > > > > > > It doesn't seem to be obvious where the problem lies, and I do not > > have access to ARM-powered Mac hardware (nor any Mac hardware for that > > matter) so I am unable to debug this....

...flac-dev digest..." > > Today's Topics: > > 1. 1.21 vs 1.3 encoding speed (Scott Brown) > 2. Re: 1.21 vs 1.3 encoding speed (lvqcl) > 3. Re: 1.21 vs 1.3 encoding speed (Scott Brown) > > > ---------- Forwarded message ---------- > From: Scott Brown <scottcbrown at gmail.com> > To: flac-dev at xiph.org > Cc: > Date: Fri, 25 Jul 2014 07:39:59 -0400 > Subject: [flac-dev] 1.21 vs 1.3 encoding speed > Hello, > > I'm on a Mac and I'm noticing that encoding via the flac command line is > significantly slower with version 1.3.0...

a. Intel 2.8 Ghz Core I7 (dual core, I7-4558U) in late 2013 Macbook Pro with Retina Display b. I compiled it the same way I compiled 1.2.1: ./configure -enable-static -disable-shared CFLAGS=" -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6" make Am i doing something wrong? Thanks, Scott On Fri, Jul 25, 2014 at 12:54 PM, lvqcl <lvqcl.mail at gmail.com>

Someone sent me a question late last night and I briefly looked at his file this morning and couldn't figure out the answer, so I'm posting here. A friend has a a ~275MB 24 bit, 48khz stereo wav file of rock music that when compressed using flac level 8 gives a flac file under 110 MB in size. When I dithered his file to 16/48 and converted that file to flac, the resulting flac file was

...il to be realised in lossy codecs, and rather little or no space saving with lossless codecs. Nicholas ----- Nicholas Wilson: nicholas at nicholaswilson.me.uk (ncw33) Site and blog: www.nicholaswilson.me.uk Peterhouse, CB2?1RD ? 86 Heath Road, GU31?4EL On 2 December 2010 13:15, scott brown <scottcbrown at gmail.com> wrote: > Someone sent me a question late last night and I briefly looked at his file > this morning and couldn't figure out the answer, so I'm posting here. > > A friend has a a ~275MB 24 bit, 48khz stereo wav file of rock music that > when compressed using f...

Hi, I've been using the command line opusenc/opusdec tools for a while now to encode/decode files. The next version of OS X changes a few things, so I was looking to recompile these tools using a version of the OS X SDK > 10.7 (needed for apple's "hardened runtime") but had no luck. How can I compile a static version of opus tools on OS X that doesn't depend on any other

...gz So I'm just looking to statically compile the current version of opus tools for OS X. I'll check out your page at https://github.com/janstary/ports/ Thanks, Scott On Tue, May 20, 2019 at 17:21:25 +0200 Jan Stary <hans at stare.cz> wrote: > Hi, > > On May 20 11:04:02, scottcbrown at gmail.com wrote: > > I've been using the command line opusenc/opusdec tools for a while now to > > encode/decode files. The next version of OS X changes a few things, > > can you be specific? > > > so I was looking to recompile these tools > > using a version...

...o be > introduced later to discard the noisiest 5% of the data. So, > heuristically I would expect most all the gains of reduced detail to > be realised in lossy codecs, and rather little or no space saving with > lossless codecs. > > > On 2 December 2010 13:15, scott brown <scottcbrown at gmail.com> wrote: >> Someone sent me a question late last night and I briefly looked at >> his file >> this morning and couldn't figure out the answer, so I'm posting here. >> >> A friend has a a ~275MB 24 bit, 48khz stereo wav file of rock >> m...

Are you sure they didn't change the default encoding level ? I would include some example timings to give a better idea of what "significantly slower" is Wonder if you see same for 44/16 files? > On Jul 25, 2014, at 2:29 AM, Martijn van Beurden <mvanb1 at gmail.com> wrote: > > Hi, > > You might want to report this to the flac-dev mailinglist instead of the

...er to discard the noisiest 5% of the data. So, >> heuristically I would expect most all the gains of reduced detail to >> be realised in lossy codecs, and rather little or no space saving with >> lossless codecs. >> >> >> On 2 December 2010 13:15, scott brown <scottcbrown at gmail.com> wrote: >> >>> Someone sent me a question late last night and I briefly looked at his >>> file >>> this morning and couldn't figure out the answer, so I'm posting here. >>> >>> A friend has a a ~275MB 24 bit, 48khz stereo wa...

ERROR while decoding data state = FLAC__STREAM_DECODER_END_OF_STREAM It's happening with every file that I've tried now, using both 1.2.1 and 1.3.0. If a file has artwork and I remove padding, I get the above error when verifying or decompressing. If no artwork and I remove padding, the file verifies and decompresses with no issues. I'm writing tags via

Hello, I'm on a Mac and I'm noticing that encoding via the flac command line is significantly slower with version 1.3.0 than 1.2.1. I'm encoding a 24/96 file to flac, both from wav and aiff and both formats are showing the same speed decrease when using 1.3.0. To give an idea of the speed decrease, encoding at flac level 8: 24/96 wav file 1.21: 61.05 seconds. ratio=0.690 1.3: 222.48

Hello, I'm on a Mac and I'm noticing that encoding via the flac command line is significantly slower with version 1.3.0 than 1.2.1. I'm encoding a 24/96 file to flac, both from wav and aiff and both formats are showing the same speed decrease when using 1.3.0. Also, 1.2.1 will not encode an aiff-c file, but 1.3.0 will. Is this change documented anywhere? Thanks, Scott --------------

I will post to the dev list, sorry about that. To give an idea, though, at flac level 8: 24/96 wav file 1.21: 61.05 seconds. ratio=0.690 1.3: 222.48 seconds. ratio=0.690 smaller 16/44.1 wav file 1.21: 14.28 seconds. ratio=0.487 1.3: 51.21 seconds. ratio=0.487 Scott On Fri, Jul 25, 2014 at 2:39 AM, <dathead2 at gmail.com> wrote: > Are you sure they didn't change the default

I want to remove padding from flac files, so I ran the following command on files with artwork in them: metaflac --dont-use-padding --remove --block-type=PADDING [filename] but now my files are corrupt. Verifying them reports a stream error and they won't decode. If the files had no picture data in them, the remove padding command did not corrupt them. Is this a bug, or did I run