Re: [flac-dev] [PATCH] Add missing functions to SeekTable class
> From: Cristian Rodríguez > Sent: Sunday, May 6, 2012 8:24 AM > > El 05/05/12 02:23, Bastiaan Timmer escribió: >> The attached patch adds the missing FLAC__metadata_object_seektable_*() >> functions from FLAC's metadata object methods (FLAC/metadata.h) to >> FLAC++'s SeekTable class. Of the 11 functions in the C API, only 4 are >> currently in the C++ API, this patch adds the missing 7. >> >> If this patch is ok, VorbisComment will be next. A quick look tells me only >> 5 out of 13 FLAC__metadata_object_vorbiscomment*() functions from >> FLAC/metadata.h exist in FLAC++'s VorbisComment class. >> >> Bas Timmer >> > This patch looks fine to me.. if applied we either need to raise the C++ > library SOVERSION and/or add a linker versioning script for *nix systems > though. Looks good to me to. Erik, are you keeping up with patches? Lately I've only been able to follow along. The soname is a good point: the flac release numbers are tied to the format and I rely on the sonames to manage binary compatibility. Some maintainers don't like it but I think it's important for users: http://flac.sourceforge.net/faq.html#api__release_versioning ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
>From: Miroslav Lichvar >Sent: Friday, May 4, 2012 9:09 AM > >On Fri, May 04, 2012 at 05:53:23PM +0200, Miroslav Lichvar wrote: >> The most interesting part of the patch is the rewrite of the >> FLAC__bitreader_read_rice_signed_block function, which in the git repo >> seems to have only couple lines changed since 1.2.1. > >Here is that part of the patch rebased against current git. In a quick >test it gives a 10% speedup in decoding. Excellent! ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to completion
By that I mean, anywhere that MM:SS:FF is accepted, so is MM:SS (whose meaning is MM:SS:00) , and further, allowing MM:SS to be used regardless of the sample rate. Then the MM:SS:00 special case can be removed; the user will always use MM:SS when the sample rate is not 44100. The tests probably also have to be augmented to cover MM:SS, and possibly the man page and html docs. > > From: Earl Chew >To: Josh Coalson ; "flac-dev@xiph.org" >Sent: Wednesday, May 2, 2012 11:13 AM >Subject: Re: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to >completion > > >Josh, > > >Sure. I can try. Would you give me a more detailed description of the >requirement ? > > >What exactly does "general MM:SS handling" mean ? > > >Earl > > > > > > From: Josh Coalson >To: Earl Chew ; "flac-dev@xiph.org" >Sent: Tuesday, May 1, 2012 8:25:34 PM >Subject: Re: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to >completion > > >Ah, I don't remember but it might have been a negative test that was supposed >to give an error when used with the wrong sample rate. > > >Anyway, could you do another patch that updates to general MM:SS handling? > > > > >> >> From: Earl Chew >>To: Josh Coalson ; "flac-dev@xiph.org" >>Sent: Thursday, April 26, 2012 3:12 PM >>Subject: Re: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to >>completion >> >> >>Josh, >> >> >>I see my name is mentioned in passing ;-) >> >> >>I submitted that patch because I thought it preferable to keep the test >>harness running. >> >> >>Backing this change out would also entail changing metaflac_test.sh >>accordingly, which at the time, I was hesitant to do. >>At the time I figured that at some point metaflac_test.sh was passing, so the >>code should probably allow it to pass. >> >> >>I'm ok either way. >> >> >> >>Earl >> >> >> >> >> From: Josh Coalson >>To: "flac-dev@xiph.org" >>Sent: Wednesday, April 25, 2012 3:23:35 PM >>Subject: Re: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to >>completion >> >> >>I haven't checked git yet but I hope this patch has not gone in. I don't >>like the special case that this is creating. >> >> >>It would be better to allow MM:SS everywhere but I consider that low priority. >> >> >> >> >>> >>> From: Earl Chew >>>To: "flac-dev@xiph.org" >>>Sent: Thursday, January 5, 2012 8:27 PM >>>Subject: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to >>>completion >>> >>> >>>When reading the INDEX from the cue sheet, the format MM:SS:FF format is >>>disallowed if the sample frequency is not a multiple of 75 because the index >>>would only be approximate. However, 00:00:00 is _exact_ because it denotes >>>the start of the track, so allow it as a special case. This allows >>>metaflac_test.sh to pass. >>> >>> >>>___ >>>flac-dev mailing list >>>flac-dev@xiph.org >>>http://lists.xiph.org/mailman/listinfo/flac-dev >>> >>> >>> >>___ >>flac-dev mailing list >>flac-dev@xiph.org >>http://lists.xiph.org/mailman/listinfo/flac-dev >> >> >> >> >> > > > >___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to completion
Ah, I don't remember but it might have been a negative test that was supposed to give an error when used with the wrong sample rate. Anyway, could you do another patch that updates to general MM:SS handling? > > From: Earl Chew >To: Josh Coalson ; "flac-dev@xiph.org" >Sent: Thursday, April 26, 2012 3:12 PM >Subject: Re: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to >completion > > >Josh, > > >I see my name is mentioned in passing ;-) > > >I submitted that patch because I thought it preferable to keep the test >harness running. > > >Backing this change out would also entail changing metaflac_test.sh >accordingly, which at the time, I was hesitant to do. >At the time I figured that at some point metaflac_test.sh was passing, so the >code should probably allow it to pass. > > >I'm ok either way. > > > >Earl > > > > > From: Josh Coalson >To: "flac-dev@xiph.org" >Sent: Wednesday, April 25, 2012 3:23:35 PM >Subject: Re: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to >completion > > >I haven't checked git yet but I hope this patch has not gone in. I don't like >the special case that this is creating. > > >It would be better to allow MM:SS everywhere but I consider that low priority. > > > > >> >> From: Earl Chew >>To: "flac-dev@xiph.org" >>Sent: Thursday, January 5, 2012 8:27 PM >>Subject: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to >>completion >> >> >>When reading the INDEX from the cue sheet, the format MM:SS:FF format is >>disallowed if the sample frequency is not a multiple of 75 because the index >>would only be approximate. However, 00:00:00 is _exact_ because it denotes >>the start of the track, so allow it as a special case. This allows >>metaflac_test.sh to pass. >> >> >>___ >>flac-dev mailing list >>flac-dev@xiph.org >>http://lists.xiph.org/mailman/listinfo/flac-dev >> >> >> >___ >flac-dev mailing list >flac-dev@xiph.org >http://lists.xiph.org/mailman/listinfo/flac-dev > > > > >___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] pkg-config output and
> From: Paul Davis
> To: flac-dev@xiph.org
> Cc:
> Sent: Friday, March 25, 2011 5:39 AM
> Subject: Re: [Flac-dev] pkg-config output and
>
> On Fri, Mar 25, 2011 at 5:32 AM, Erik de Castro Lopo
> wrote:
>> Hi,
>>
>> FLAC helpfully provides a flac.pc file. Unfortunately there is a
>> nasty interaction between that file and system header files.
>>
>> If ones installs flac and relies on pkg-config to find the CFLAGS
>> one woulf get CFLAGS value of "-I${includedir}/FLAC" which
> suggests
>> that FLAC header files like should be included as:
>>
>> #include
>>
>> However, FLAC also ships an header file. If one writes
>> code that wants needs both the Standard C and the FLAC
>> header files, we run into a problem, the C compiler finds FLAC's
>> instead of the Standard C version.
>>
>> I believe the correct solution to this problem is the change the
>> Cflag value in flac.pc to "-I${includedir}" and then encourage
>> people to use:
>>
>> #include
>> #include
>> #include
>>
>> which will no longer conflict.
>>
>> Opinions?
>
> i recall raising this as an issue about 18 months ago. i certainly
> feel that the include style that flac uses now is simply wrong, and
> that your suggestion above (which matches the one i made) is
> substantially preferable.
I didn't follow, which style is wrong? I never liked lazy search paths like:
-I.../include/FLAC
#include
because of the potential for conflict with other headers. The code
should be using this style everywhere:
-I.../include
#include
Then there is no problem with
#include
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to completion
> From: Erik de Castro Lopo > To: flac-dev@xiph.org > Cc: Josh Coalson > Sent: Wednesday, April 25, 2012 4:30 PM > Subject: Re: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to > completion > > Josh Coalson wrote: > >> I haven't checked git yet but I hope this patch has not gone in. I >> don't like the special case that this is creating. >> >> It would be better to allow MM:SS everywhere but I consider that low > priority. > > I modified version of that patch did go in. See the following commits: > > https://git.xiph.org/?p=flac.git;a=commit;h=19050f74eaa1aa6d609ca065e1a854ada5bb6b4c > https://git.xiph.org/?p=flac.git;a=commit;h=7ee908403e8be011b8a7dd3bf511408b40312c2e > https://git.xiph.org/?p=flac.git;a=commit;h=ce8a75134cace056f6c436d54b57bad1a1d93797 > > > Erik I saw. I like almost all the progress on recent patches but not this one. Can it be backed out or replaced with proper MM:SS handling? ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
From: Erik de Castro Lopo >To: flac-dev@xiph.org >Cc: Josh Coalson >Sent: Wednesday, April 25, 2012 4:42 PM >Subject: Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32 > >Josh Coalson wrote: > >> But regardless of submitter, any patch that affects encoding must be >> reviewed very carefully, preferably by several other people and definitely >> me. > >Is there any way of encoding this manual review process in the test suite >so that people hacking on FLAC can immediately see that soemthing is wrong >before even attempting to submit a patch (assuming they run the test suite)? > >Erik Part of the reason the current test suite is so long is to try and discover those problems automatically. But it's not possible to be exhaustive simply because new code may not be covered by the test suite. Encoder bugs can be very subtle and sometimes it takes someone with good knowledge of the format to notice. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
(Jumping in again, maybe at the wrong point since this doesn't seem to involve encoding, but here goes.) Miroslav's patches have always been high-quality for sure. But regardless of submitter, any patch that affects encoding must be reviewed very carefully, preferably by several other people and definitely me. If there were ever a libFLAC release that had a bug and was not always lossless, that would be very damaging to the format. Miroslav, sorry for dropping the ball on your patches; if I wasn't able to review properly then I didn't put it in, just out of caution. Somewhere in my mailbox they're still there waiting to be looked at :) Also, please keep an eye if you can on critical commits because you always were a good reviewer too. > > From: Erik de Castro Lopo >To: flac-dev@xiph.org >Sent: Friday, February 10, 2012 1:39 AM >Subject: Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32 > >Miroslav Lichvar wrote: > >> I'd like to see the following patch included. It's not trivial, but I >> think it's very well tested after those years. >> http://www.mail-archive.com/flac-dev@xiph.org/msg00914.html >> >> An updated version of the patch which includes some other >> optimizations is here. >> http://pkgs.fedoraproject.org/gitweb/?p=flac.git;a=tree > >I've had a look at that, but it doesn't apply to current git >head and I'd like to have a bit of an explanation of what it >does and why. > >> There are other patches which I think you might find useful: -asm, >> -gcc43 and -hidesyms. > >Likewise for those. > >> I can prepare proper git patches, if interested. > >Patch with an explanation of what and why would be awesome. > >Current git head is here: > > https://git.xiph.org/?p=flac.git;a=summary > >Cheers, >Erik >-- >-- >Erik de Castro Lopo >http://www.mega-nerd.com/ >___ >flac-dev mailing list >flac-dev@xiph.org >http://lists.xiph.org/mailman/listinfo/flac-dev > > >___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Meet the new maintainer
No, this has been addressed before. The FLAC format has no compression levels or even any encoding parameters that cannot be gleaned from the frame headers. Everything else is implementation-specific and doesn't need official metadata support for. > > From: Olav Sunde >To: flac-dev@xiph.org >Sent: Monday, February 6, 2012 3:16 AM >Subject: Re: [flac-dev] Meet the new maintainer > > >At 09:33 02.02.2012, you wrote: >Thanks Erik, I'll check back. > >This next is a feature request: Today it is not possible to know the encoding of a flac archive. Many new devices support playback of flac, however tiny processors sometimes have a hard time decoding files with the default encoding of -5 or higher, resulting in unstable playback or even reduced audio quality. A re-encoding to -0 often solve these issues. >Can you look at a way to store parameters used for encoding in an archive so we can check it later? > >Best regards > >Olav Sunde > > > >Olav Sunde wrote: >> >>> very good to see activity on flac development again. I am not a developer >>> unfortunately, but I'd like to check with you if updating code for >>> flac/metaflac to handle high-rez files (24/192 or higher) for writing Replay >>> Gain tags is in your 'pile' of things to fix? >> >>I think there are patches to do that in the queue. Perhaps you can check >>back in two weeks or so. >> >>Cheers, >>Erik >>-- >>-- >>Erik de Castro Lopo >>http://www.mega-nerd.com/ >>___ >>flac-dev mailing list >>flac-dev@xiph.org >>http://lists.xiph.org/mailman/listinfo/flac-dev >___ >flac-dev mailing list >flac-dev@xiph.org >http://lists.xiph.org/mailman/listinfo/flac-dev > > >___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Meet the new maintainer
I'll throw this thought out here so it doesn't get lost: when it came time for me to build a Windows release, I always used a quarantined Windows box that had the minimum stuff installed and had never been on a network, to avoid malware getting into the binaries. The last thing I ever wanted to hear was some Windows user blaming FLAC because a bad build infected him. It was bad enough when some AV software was misidentifying a release as infected; it took months after the virus defs were updated for that stink to wear off. > > From: Erik de Castro Lopo >To: flac-dev@xiph.org >Sent: Saturday, February 4, 2012 9:16 PM >Subject: Re: [flac-dev] Meet the new maintainer > >Ralph Giles wrote: > >> On 4 February 2012 14:30, Erik de Castro Lopo wrote: >> >> > Is there any way to add say a windows machines with MSVC to that? :-) >> >> There is. It's slightly complicated because (a) I don't have a windows >> machine with a public IP jenkins can ssh to, and (b) the jenkins box >> itself doesn't have a public IP the java blob jenkins provides can >> phone home to. >> >> I need to set up appropriate tunnels or packet forwarding. > >Would be very cool if you could set that up. Having Jenkins test >on the platform that I do all of my hacking on is not all that >useful. Having Jenkins test on Windows and OS X would be *really* >useful. > >Erik >-- >-- >Erik de Castro Lopo >http://www.mega-nerd.com/ >___ >flac-dev mailing list >flac-dev@xiph.org >http://lists.xiph.org/mailman/listinfo/flac-dev > > >___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to completion
I haven't checked git yet but I hope this patch has not gone in. I don't like the special case that this is creating. It would be better to allow MM:SS everywhere but I consider that low priority. > > From: Earl Chew >To: "flac-dev@xiph.org" >Sent: Thursday, January 5, 2012 8:27 PM >Subject: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to >completion > > >When reading the INDEX from the cue sheet, the format MM:SS:FF format is >disallowed if the sample frequency is not a multiple of 75 because the index >would only be approximate. However, 00:00:00 is _exact_ because it denotes the >start of the track, so allow it as a special case. This allows >metaflac_test.sh to pass. > > >___ >flac-dev mailing list >flac-dev@xiph.org >http://lists.xiph.org/mailman/listinfo/flac-dev > > >___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] mid-side coding and bits per sample
the side channel bps is 1 larger than the raw bps because it's a difference
between left and right channel values.
>
> From: Eri Eri
>To: flac-dev@xiph.org
>Sent: Monday, September 26, 2011 1:17 AM
>Subject: [Flac-dev] mid-side coding and bits per sample
>
>
>
>Dear list,
>
>i'm doing a bit of analisys on flac's source code and i've run into something
>i can't quite grasp.
>
>flac version 1.2.1
>
>flaclib C
>
>stream_encoder.c
>
>function "process_subframes_"
>
>line 2999
>
>++
> if(do_mid_side) {
> FLAC__ASSERT(encoder->protected_->channels == 2);
> for(channel = 0; channel < 2; channel++) {
> const unsigned w =
>get_wasted_bits_(encoder->private_->integer_signal_mid_side[channel],
>encoder->protected_->blocksize);
>
>encoder->private_->subframe_workspace_mid_side[channel][0].wasted_bits =
>encoder->private_->subframe_workspace_mid_side[channel][1].wasted_bits = w;
> encoder->private_->subframe_bps_mid_side[channel] =
>encoder->protected_->bits_per_sample - w + (channel==0? 0:1);
> }
> }
>
>
>In that piece of code the encoder determines how many wasted bits there are in
>each channel (mid-side) and calculates effective BPS for each of them. What i
>don't understand is why it should add one bit to the BPS of the side channel
>"(channel==0? 0:1)", eventhough there is no "correction" to wasted bits. Could
>someone shed light on this?
>Thank you very much in advance!
>
>___
>Flac-dev mailing list
>Flac-dev@xiph.org
>http://lists.xiph.org/mailman/listinfo/flac-dev
>
>
>___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Back from hiatus
Hi all, this is not really FLAC-specific but I'm back after being away from the lists for too long. I'm caught up to about Sep 2011 and working my way through. There are some plans to move the website and possibly the source code management/releases completely to Xiph; more on that soon. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Difficulties in add cover art to FLAC file
how big is the data? there's a 16MB limit for metadata blocks. see src/share/grabbag/picture.c:grabbag__picture_parse_specification() for examples of function usage. --- On Mon, 3/8/10, Anthony Liu wrote: ... The above code will add a NULL cover art into the flac file, it works. However, after I add the following code between the call of FLAC__metadata_iterator_next and FLAC__metadata_object_picture_is_legal, I got a "fail to write: status 0" message. ... I did some tests and it seemed that the error was caused by the FLAC__metadata_object_picture_set_data function, the members of picture object like width, height, depth, colors were not initialized, are they mandatory or optional? What's wrong with the code? Please help! ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] GPU-enabled FLAC encoder available
there is no work on the reference tools because it's not very portable (way less than the current asm optimizations). the third party implementations are good enough I think. --- On Fri, 1/1/10, Sumit Gupta wrote: Is anyone on this mailing list working on enabling FLAC using GPUs? There is CUDA (GPU) accelerated FLAC encoder available now at:http://www.cuetools.net/doku.php/flacuda It has a chart with speedup results and here is a summary:Compared to reference flac 1.2.1 on Core i7 940, it runs approximately 10 times faster on GeForce GTX 285, when using higher compression ratios (modes -7, -8). FlaCuda -8 is faster than flac -0, and provides better compression than flac -8. I am not a FLAC developer, but am curious to find out how 3rd party projects like this oneare interfaced into the FLAC sourceforge project. Thanks ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] can flac be ported to ARM platform?
it already has been built for arm in many places. I built a version for my nslu from the original sources, with no modifications. --- On Thu, 1/7/10, 刘祥辉 wrote: hi,everybody, i have download the flac-1.2.1.tar.bz2 f,and rebuild it in ubuntu on my PC,and it works as a plugin of XMMS,now i want to port the flac to ARM platform,can this available? if does ,which files need be modified? thanks a lot. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Win32 and ELF created files are different
http://flac.sourceforge.net/faq.html#tools__different_sizes one example of variations: whether binary was compiled w/sse support or not (affects computation of lpc coefficients) --- On Tue, 2/9/10, Djeizon Barros wrote: > Hi everyone, > > I was fiddling with FLAC executable on Linux and also > making FLAC files with foobar2000 under WINE. I was using > the same exact options for both linux native executable and > flac.exe through foobar2000. But I have noticed something: > The FLAC files themselves created from flac.exe and > flac(ELF) are not bit identical. They differ in something > (Not audio data). > > Looking at this, I used a Windows native installation to > check about this and confirmed that the flac.exe in Windows > is also creating a file that differs a little than the flac > ELF. At first glance I compared the metadata and it seemed > that metaflac returned different stream_offsets from the > seektable, comparing the same music file created with > flac-win and flac-lin. Then I removed entirely both their > tags & padding, but they still are different. > > Is this normal? Music data is absolutely untouched, > however, can this be an architecture difference between the > compilers that made the Win32 and ELF executables? Just for > the record, what is exactly making the files different? ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Recent gcc compilation
--- On Sat, 3/27/10, Ruben Van Boxem wrote: > I was compiling flac 1.2.1 from msys with mingw-w64 which works > splendidly, except for one thing: examples/cpp/encode/file/main.cpp > gives an error about memcmp not being declared in this scope, which > is correct. Solution is to add #include which does declare > memcmp. yep, you're right, this is fixed in cvs. > By the way, when will there be a new release of flac? Doesn't have > to be big, just some x64 windows support (in the MSVC project files, > mingw-w64 works as far as I'm concerned :) and perhaps any bugs > squashed. hard to say, all releases are big because of the testing involved and number of platforms, and I don't have much time to devote lately. current cvs is in pretty good shape though. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Translation to spanish
--- On Wed, 10/14/09, Fernando Alberto Marengo Rodriguez wrote: > Dear list, > > Following Victor Westmann's idea, I'd like to > translate FLAC's site to Spanish. I'd be very > grateful if anyone offers to give me a hand in this. thanks Fernando, I will keep it in mind. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Detecting FLAC file type
--- On Tue, 10/6/09, Shayne Wissler wrote: > Hello, > > I have a program that is given a random file and needs to determine > whether it is Vorbis or FLAC. For Vorbis, there are various places > where I can infer that I have a bad stream. But for FLAC, when I call > either FLAC__stream_decoder_process_until_end_of_metadata or > FLAC__stream_decoder_process_single, it searches the entire file > before giving up. I'd like it to stop searching as soon as it loses > sync, or find some better way to detect the file type without scanning > the whole file. Any tips on the best way to do that? hmm, you should be getting a call to your error callback with FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC on the first sync error. then right away you can abort. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] General status of flac
--- On Sun, 9/20/09, grarpamp wrote: > From: grarpamp > Subject: Re: [Flac-dev] General status of flac > To: flac-dev@xiph.org > Date: Sunday, September 20, 2009, 8:30 PM > >> used it forever anyways and > haven't seen a commit since January nor > >> a release since 2007... > > > what's queued up for the next release, see > > http://flac.cvs.sourceforge.net/viewvc/*checkout*/flac/flac/doc/html/changelog.html > > Hmm interesting, so given the above timeframes, should one > presume > that cvs head is indeed stable/release quality and that > it's an ok > thing to use? > > My scripts save the input wav md5's/sha256's and run flac in pipe decode > mode before nuking the wav's as a sanity check anyways. Only problem > I ever had was that flac served as a pretty good bad ram detector :) I suppose > I should put head through it's make test thing. there have not been any fundamental changes to the encoding algorithm. the only real change that might introduce problems is the rf64/wave64 stuff which required reorganization in the flac commandline, and there's a remote possibility there is some unexposed bug due to that. I routinely run the whole test suite before major checkins and have not found anything so far. if you do a separate decode to wav and then compare, you are quite safe. it looks like I won't be able to get to an official release until I take some time off my day job. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] (Universal) Ambisonic implementation
--- On Thu, 9/17/09, e deleflie wrote: > Hi Flac Developers, > > My name is Etienne Deleflie, I'm the founder of > http://www.ambisonia.com and, more recently, http://soundofspace.com. > > Myself and the community I serve are looking for a lossless file > format that can encapsulate ambisonic encoding. To this end a > specification has been drafted, and is nearing stability, that > describes practical features designed to get the most out of > ambisonics. > > That spec is accessible here: > http://ambisonics.googlegroups.com/web/Universal_Ambisonic_0.96.pdf > > I'm wondering if the FLAC community might be interested in > implementing a lossless implementation of that spec. I know there are > some current incompatibilities. I'm also aware that there are certain > open source processes involved around implementing new features. I'd > be happy to get involved with those processes if someone expressed > interest at implementing these features. this is cool but would actually be a lot of work and require extensions to the flac format. it's not something that I would be able to do for the foreseeable future. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Flac and lyrics
--- On Mon, 8/31/09, Jérôme COUDERC wrote: > Hi, > > I haven't seen any information about Lyrics in the documentation and > mail archives, so I guess the answer... but may be I've missed something... > Does flac support lyrics? I think most people are just putting it in a LYRICS tag. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] General status of flac
--- On Sun, 8/30/09, grarpamp wrote: > Hi. I'm preparing to start a major encoding project, about a TiB > or so. Flac is one of the components I plan on using. As I've > used it forever anyways and haven't seen a commit since January nor > a release since 2007... > > Is there a general status of flac along with a roadmap > available? the format is pretty mature (almost 10 years) and stable. there are no format changes planned. that's a good thing for a codec, not bad. the tools in the release are also pretty mature. if you want to see what's queued up for the next release, see http://flac.cvs.sourceforge.net/viewvc/*checkout*/flac/flac/doc/html/changelog.html ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] floating point
--- On Fri, 8/14/09, Paul Davis wrote: > On Fri, Aug 14, 2009 at 5:05 PM, Josh Coalson > wrote: > > it's unlikely flac will ever support floating-point > > samples natively. the main application for it is audio > > engineering, which demands easy editing and very high speed > > for both encoding and decoding above everything else. > > thats not why floating point is used. I'm not saying that, I'm saying float is mainly used in audio engineering which has different requirements and tradeoffs > > flac is designed as a consumer audio format. it > > trades ease of editing for a featureful, robust transport > > layer more suited for playback, and encoding speed for more > > compression and faster decompression. > > flac seems more popular at present among high end audiophiles than > mere consumers. its very regrettable that it doesn't support floating > point natively. many of our users (http://ardour.org/) have asked > about using FLAC as an option for recording format, but we have to > explain that its not viable because of the lack of floating point > support. and yes, that is audio engineering :) for export it might be useful, but for recording and editing, a simple, fast codec and easily editable stream format is much more suited. you cannot easily snip an arbitrary section out of a flac or wavpack stream. a very simple float-only codec could be very fast and probably still get compression within 10% of say wavpack. if by audiophiles you are talking about people listening to the end product, properly mastered 16 bit material is mostly indistinguishable from even 24 bit. 32 bit int is beyond overkill. 32 bit float is not even necessary because the dynamic range is fixed in the end result. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] floating point
--- On Fri, 8/7/09, Didier Dambrin wrote: > Hi, > > I've tried to find info about unofficial 32bit > float support in FLAC, and found several conversations. > > Most of them were talking about a 24bit limit, > but from the manual I guess that this limitation is gone, > as it supports up to 32bit integer. > > So my question is, what would be the best way, or > what is a common way to FLAC-encode floating point > audio? it's unlikely flac will ever support floating-point samples natively. the main application for it is audio engineering, which demands easy editing and very high speed for both encoding and decoding above everything else. flac is designed as a consumer audio format. it trades ease of editing for a featureful, robust transport layer more suited for playback, and encoding speed for more compression and faster decompression. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] 32-bit sample size
--- On Sun, 6/7/09, Justin Ruggles wrote: > Hi, > > I have a question about 32-bit sample size. It is obviously not > supported in encoding or decoding in libFLAC, but is allowed in the > format description. The only way to allow it is in the STREAMINFO, > which means that the files would not be Subset compatible. The Subset > constraints list the value of 7 as allowed, even though it is reserved. > > So my real question is: Is the value of 7 meant to be used for 32-bit > eventually? If so, will 32-bit be Subset compatible at that point? I would probably lean more toward using 3 for 32-bit samples, because 7 could increase the likelyhood of false sync codes occurring if some of the other reserved bits came into use. absent a strong demand for 32 bit though, I would prefer to leave as is due to the disruptive effect of defining new bits. there is probably no problem with 32-bit being or not being in the subset. subset decoders can reject unsupported sample rates; at the same time I think any application handling 32-bit samples will not be constrained in a way the subset tries to mitigate. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Bug in bitreader for short reads?
fixed in cvs
http://sourceforge.net/tracker/?func=detail&aid=2490454&group_id=13478&atid=113478
--- On Mon, 6/1/09, Gilles Boccon-Gibod wrote:
> From: Gilles Boccon-Gibod
> Subject: [Flac-dev] Bug in bitreader for short reads?
> To: flac-dev@xiph.org
> Date: Monday, June 1, 2009, 10:16 AM
> It seems that the bitstream
> reader is not working as it should (verified in version
> 1.2.0 and 1.2.1).The problem is as follows: if the data
> read by the read callback is not a multiple of 4, the bit
> reader will end up in a very bad state, where the
> bits_consumed field will grow without ever being reset to 0,
> and that causes everything to fail.This is not a
> case that's encountered very often, because in general
> (like for example when reading from a file), the read
> callback will return as many bytes as were asked for, which
> happens to be a multiple of 4. But when reading from a
> network socket, or some type of buffering code, it can
> happen that reads are shorter than requested, and not always
> multiples of 4, and that produces decoding
> problems.The problem is very easy to reproduce:
> in the read callback, always return 1 byte, regardless of
> how many bytes are asked for.For example, in a
> typical read callback routine, one can do the (simplified)
> following and see the problem:
> static
> FLAC__StreamDecoderReadStatus FlacDecoder_ReadCallback(const
> FLAC__StreamDecoder* flac,
> FLAC__byte
>
> buffer[],
> size_t*
>
> bytes,
> void*
>
> client_data){*bytes=1;
> /* <--- this was added to always return at most
> one byte */
> read_only_one_byte_into_buffer(buffer);
> return
> FLAC__STREAM_DECODER_READ_STATUS_CONTINUE;}
>
> Any hints on how to get this fixed?
> -- Gilles
> -Inline Attachment Follows-
>
> ___
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC decoding details
--- On Sun, 4/5/09, Jonathan Lee wrote: > Can the bits per sample change from frame to frame? no, not in the native container (i.e. fLaC header + metadata + frames). in a raw streaming situation where you are getting only frames it might be advantageous to support it but I don't know of anything that works like that. > Can constant or verbatim subframes have left/side, > right/side, or mid/side channel assignment? If so, does the > difference channel have an extra bit per sample? good question... yes it is possible and the difference channel always has the extra bps. > Is it a fatal error if the minimum frame size is larger > than the maximum frame size (in STREAMINFO)? What about the > minimum number of samples being larger than the maximum > number of samples? they're not fatal. the STREAMINFO is to help inform the decoder but if you detect invalid values it should be treated as if those values are unknown. a decoder implementation with limited memory is allowed to fail if it can't get accurate STREAMINFO that it needs though. this is an implementation detail though. > If the residue bit width is given by an escape code, can > this escape code be zero? What is the effect of reading > "zero" bits? (assuming that the stream is not > advanced and 0 is the value read) another good one. an escape code of 0 is invalid; should be treated as reserved for use by a future encoder. > The MD5 is calculated on the "unencoded data", > but this leaves a lot of room for interpretation. Does this > mean the data produced by the decoder, or the data that was > passed to the encoded when the file was made? If it means on > produced data, are the channels interleaved? Stored as big > or little endian? If it means the original data, how can we > be sure of the format of that data? this is ill-specified, but it is the channel-interleaved signed samples, samples truncated to the smalled number of bytes that can represent the sample, then converted to bytes by shifting LSBs 8 bits at a time into the MD5 accumulator. see src/libFLAC/md5.c:format_input_() > How do I handle negative QLPC shifts, officially? Treat > them as positive left shifts? Or treat them as an error > condition? Or treat them as a right shift with the shift > index taken modulo 32 (as apparently happened with earlier > versions of the reference code)? this one's going to haunt me forever... the reference encoder has avoided negative shifts entirely since 1.1.4. negative shifts were meant to be positive shifts in the opposite direction but they were implemented directly with << >> and in C negative shifts are undefined. treat as an error for now to avoid bad behavior but I need to come back to this to specify exactly. > If I read a signed value that is one bit, what is > "1" equal to? -1 > If a sample rate of zero is specified, is this a fatal > error? Or should it be ignored? it is technically an invalid sample rate, even though the codec does not care about the sample rate (it is merely stored and passed on for playback). I think the reference decoder does not fail on it but it should. Josh ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Support for CAF in flac command-line?
new tracker item here: https://sourceforge.net/tracker2/?func=detail&aid=2491177&group_id=13478&atid=363478 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC Test files
--- Daniel Önnerby wrote: > Hi all! > > I'm implementing FLAC playback in mC2 (a rewrite of musikCube) and > need > to test if everything is working. > I was wondering if there are any FLAC test files to download? > I'm looking for files with diffent kind of bits (8,16,24 etc) and > examples of multichannel files. the test suite makes a bunch of them. some are generated by programs in src/test_* that must be compiled. some are generated by the test suite in test/ since this gets asked from time to time, I created this request that you can monitor: https://sourceforge.net/tracker2/?func=detail&aid=2491167&group_id=13478&atid=363478 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] libFLAC header checking
--- LRN wrote:
> On 06.11.2008 22:16, LRN wrote:
> > In stream_decoder.c function find_metadata_() checks whether a file
> is
> > valid or not. There are 4 cases it recognizes:
> > 1) file begins with 'fLaC'
> > 2) file begins with ID3 (skipped), followed by 'fLaC'
> > 3) file may begin with 10?? sync code (or
> 10,
> > depends on endianess i suppose). That is - a raw file with FLAC
> > frames, without header (right?).
> > 4) file begins with ID3 (again - skipped), followed by the same
> sync
> > code as in case 3
> >
> > find_metadata_() accepts all 4 types of files.
> >
> > I don't know what was the intention behind accepting case 3, but
> case
> > 4 ALSO matches mp3 files - they have ID3 at the beginning and
> > FLAC-like two-byte sync code 1011 afterwards. Sequence
> is
> > slightly different, but when it is read as two separate bytes and
> the
> > second byte is SHR'ed twice to form 0010, it matches.
> > Because of this FLAC decoder initially accepts an mp3 file as a
> valid
> > FLAC file. Of course, once decoding starts, decoder throws an error
>
> > and discards the file (at least i think it does, i never reached
> that
> > far myself).
> > Unfortunately, some applications using libFLAC may assume that lack
> of
> > errors after FLAC__stream_decoder_process_until_end_of_metadata()
> > indicates that header is read and stream information (channel
> number,
> > for example) is available.
> >
> > Would you kindly check the find_metadata_() function to make sure
> it
> > only accepts real FLAC sync codes, not the MP3 ones? Or at least
> > mention in the documentation that FLAC__STREAM_DECODER_READ_FRAME
> > status doesn't means that stream info is available.
> Further information:
>
> FLAC header:
> 10AB and so on
>
> A =
> 0 - mandatory
> 1 - reserved
> B =
> 0 - fixed-blocksize
> 1 - variable-blocksize
> =
> - reserved
> 0001 - 192 samples
> 0010-0101 - 576 * (2^(n-2)) samples
> 0110 - get 8 bit (blocksize-1) from end of header
> 0111 - get 16 bit (blocksize-1) from end of header
> 1000- - 256 * (2^(n-8)) samples
>
> MP3:
> 111BBCCD and so on
>
> BB =
> 00 - MPEG 2.5
> 01 - reserved
> 10 - MPEG 2
> 11 - MPEG 1
> CC =
> 00 - reserved
> 01 - layer 3
> 10 - layer 2
> 11 - layer 1
> D =
> 0 - with CRC
> 1 - without CRC
>
> The best way to distinguish FLAC header from MP3 header is to look at
>
> "0A" (FLAC) or "CC" (MP3) bit pair.
> In FLAC it must be 00 (first 0 is from magic number second 0 is from
> reserved bit that should always be 0)
> In MP3 it must not be 00 (00 is reserved).
>
> Suggested code change is
> from:
> else if(x >> 2 == 0x3e) { /* MAGIC NUMBER for the last 6
>
> sync bits */
> decoder->private_->header_warmup[1] = (FLAC__byte)x;
> decoder->protected_->state =
> FLAC__STREAM_DECODER_READ_FRAME;
> return true;
> }
> to
> else if(x >> 1 == 0x7c) { /* MAGIC NUMBER for the last 6
>
> sync bits and reserved 7th bit*/
> decoder->private_->header_warmup[1] = (FLAC__byte)x;
> decoder->protected_->state =
> FLAC__STREAM_DECODER_READ_FRAME;
> return true;
> }
I like this. it's kind of a lucky coincidence that the CC bit
patterns are exclusive between the 2 formats. I'll make the fix
and also add a note about the reserved bit to the format docs.
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Possible (bug) in winamp in_flac.dll decoder
sorry, sent this to the wrong list --- Josh Coalson wrote: > Date: Tue, 16 Dec 2008 17:44:13 -0800 (PST) > From: Josh Coalson > To: "engelbert...@gmx.de" , f...@xiph.org > Subject: Re: [Flac] [Flac-dev] Possible (bug) in winamp in_flac.dll > decoder > > --- "engelbert...@gmx.de" wrote: > > Does anybody know how to contact jcoalson (Josh Coalson)? > > that's me but I really don't know much about winamp internals > or how to fix it. > > the recent dates on the files are probably trivial changes > (copyright notice, etc). no work has been done on it in a > long time. > > > > > ___ > Flac mailing list > f...@xiph.org > http://lists.xiph.org/mailman/listinfo/flac > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Support for CAF in flac command-line?
--- Martin Leese <[EMAIL PROTECTED]> wrote: > Brian Willoughby <[EMAIL PROTECTED]> wrote: > > Hello all, > > > > Is anyone here potentially up to the task of adding support for CAF > > (the CoreAudio Format) into the flac command-line? > ... > > I've already made some recordings > > that are so long that they cannot be uncompressed from FLAC to WAV > or > > AIFF because they would exceed 4 GB - the maximum file size for > those > > formats. CAF does not have the same 4 GB limitations. > > Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > ... > > Whats more, the sndfile-convert program can also convert > > from FLAC to the following file formats that support 63 bit > > file offsets: > > > >Au, Caf, rf64, w64 > > I am glad somebody mentioned RF64. > Supporting RF64 instead of CAF would solve > Brian's problem equally well, and would be the > natural extension to supporting WAVE. BTW current flac in CVS supports RF64 and wave64; they will be in the next release. I'll have to look into CAF. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] MinGW Patch
ok, done! --- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Erik de Castro Lopo wrote: > > > will surgent wrote: > > > > > Hello, I was trying to compile Flac on MinGW/Msys but got an > error stating > > > SIZE_T_MAX is undefined. > > > To fix this error I edited the file > "flac-1.2.1/include/share/alloc.h" and > > > made the following change: > > Would it be possible to get this patch applied? I still hit this > every time I try to compile with MinGW. > > Cheers, > Erik > -- > - > Erik de Castro Lopo > - > Traditional capital was stuck in a company's bank account or > investments. > It could not walk away in disgust. Human capital has free will. It > can > walk out the door; traditional capital cannot. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] 1.2.1 pkg-config file "error"
good catch, fixed in CVS --- Paul Davis <[EMAIL PROTECTED]> wrote: > hi, and sorry that my first post to the list is a complaint. > > the .pc file for 1.2.1 produces this for --cflags: > > -I$PREFIX/include/FLAC > > i humbly suggest that this is wrong. it appears to support inclusion > of > FLAC headers with > > #include > > rather than > > #include > > but more importantly, it means that when building an app using > pkg-config to determine compiler flags, we end up with a rather > serious > problem as soon as the app uses "assert.h": > >#include > > combined with: > >-I/usr/local/include/FLAC > > means that we find the FLAC assert.h file first. this file the tries > to > help out by doing > > #include > > which simply causes it to include itself again. > > The .pc.in file should use $PREFIX/include for the cflags, not > $includedir which is where the headers are installed. apps should use > to include FLAC headers, not as this > mistake with assert.h demonstrates. > > --p ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC DLL available?
--- Susan Henderson <[EMAIL PROTECTED]> wrote: > Hi all, > > I have been looking for a FLAC code/decode program in DLL > format, and I have downloaded from dlldll.com the following: > >FLAC.dll > > However, I have no idea how to use it as I can't find any > documentation about it. > > Question: Is there an official FLAC.dll that is available > suitable for non-OGG use, and where can I find the API interface? yes, you need flac-1.2.1-devel-win.zip from here: http://sourceforge.net/project/showfiles.php?group_id=13478&package_id=12675 that has DLLs, static libs, and headers. the API is documented here: http://flac.sourceforge.net/api/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] are 588 sample frames subset or nonsubset?
ok, the docs are correct and the stream encoder is being too strict in what it allows. I've checked in a fix but in the meantime you can encode with the --lax argument if you are using a blocksize of 588 and the resulting files will still be subset. Josh --- Josh Coalson <[EMAIL PROTECTED]> wrote: > hi Howard, I'll check into the discrepancy but having the FLAC > blocksize match the CD sample frame size is probably not desirable. > the optimal blocksize for FLAC is relative to the stationarity of > the signal and the 588 sample frame is not related to that, it's > an artifact of optimal storage on CD. > > Josh > > --- Howard Farrar <[EMAIL PROTECTED]> wrote: > > > Hi > > > > I am thinking of ripping albums to a single flac file with embedded > > cuesheet. As track and index points have to be on a 588 sample > > boundary due > > to the CD TOC standard working in 588 sample frames, I thought it > may > > be beneficial to rip CDs with a blocksize of 588 samples. > > > > According to the format page on sourcefourge a stream is subset if > > > > "The blocksize bits in the frame header must be 0001-1110. > > The blocksize must be <=16384; > > if the sample rate is <= 48000Hz, the blocksize must be <=4608. > > > > As far as I can tell, this means that a blocksize of 588 should be > > subset, > > although the blocksize would be a 16 bit value at the end of the > > frame > > header. > > > > However when I try encoding with flac 1.2.1 it says that only the > > blocksizes > > that can be represented in the 4 bits in the early part of the > frame > > header. > > > > Which is correct? Can anyone forsee any problems with encoding > with > > a block > > size of 588 samples? > > > > Best Regards > > > > Howard > > > > > > Meridian Audio Ltd - www.meridian-audio.com - Registered in England > > Registered Office: 11 Latham Road, Huntingdon, Cambs, PE29 6YE, UK > > Company Registration No. 2710631 VAT Registered No. GB576660505 > > > > > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] are 588 sample frames subset or nonsubset?
hi Howard, I'll check into the discrepancy but having the FLAC blocksize match the CD sample frame size is probably not desirable. the optimal blocksize for FLAC is relative to the stationarity of the signal and the 588 sample frame is not related to that, it's an artifact of optimal storage on CD. Josh --- Howard Farrar <[EMAIL PROTECTED]> wrote: > Hi > > I am thinking of ripping albums to a single flac file with embedded > cuesheet. As track and index points have to be on a 588 sample > boundary due > to the CD TOC standard working in 588 sample frames, I thought it may > be beneficial to rip CDs with a blocksize of 588 samples. > > According to the format page on sourcefourge a stream is subset if > > "The blocksize bits in the frame header must be 0001-1110. >The blocksize must be <=16384; >if the sample rate is <= 48000Hz, the blocksize must be <=4608. > > As far as I can tell, this means that a blocksize of 588 should be > subset, > although the blocksize would be a 16 bit value at the end of the > frame > header. > > However when I try encoding with flac 1.2.1 it says that only the > blocksizes > that can be represented in the 4 bits in the early part of the frame > header. > > Which is correct? Can anyone forsee any problems with encoding with > a block > size of 588 samples? > > Best Regards > > Howard > > > Meridian Audio Ltd - www.meridian-audio.com - Registered in England > Registered Office: 11 Latham Road, Huntingdon, Cambs, PE29 6YE, UK > Company Registration No. 2710631 VAT Registered No. GB576660505 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Memory leaks due to Metadata object vorbis comment API ???
sorry about the delay, I replied here: http://www.hydrogenaudio.org/forums/index.php?showtopic=63444 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] New verbosity in command line flac: progress-silent
if you have a sourceforge account, can you create a tracker here? http://sourceforge.net/tracker/?func=add&group_id=13478&atid=363478 --- Jean-Luc Wasmer <[EMAIL PROTECTED]> wrote: > Hi, > > Would it be possible to add a new verbosity level? [...] ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Patch : Fix cross-compiling from Linux to windows
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Hi all, > > The following patch fixes cross compiling from Linux to windows. > > The existing code was doing: > > #if !defined _MSC_VER && !defined __MINGW32__ && !defined __EMX__ > #include /* for SIZE_MAX in case limits.h didn't get > it */ > #endif > > when it seems to make much more sense to just test for the presence > of and do: > > #ifdef HAVE_STDINT_H > #include /* for SIZE_MAX in case limits.h didn't get > it */ > #endif hmm, ok, will do that. the VC projects will also have to be fixed because they don't have a config.h > It is [now] possible to cross compile from Linux to windows, but the > tests don't currently work. Josh, are you interested in fixing > this? It should be possible to run the tests under Wine. the tests work for me under cygwin, I run them for every release. what happens for you? ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC__metadata_get_picture()
that is a convenience function for trying to get the best picture
that matches a constraint. to get more than one, you should use
one of the iterator interfaces:
http://flac.sourceforge.net/api/group__flac__metadata.html
--- "Alex J. Ivasyuv" <[EMAIL PROTECTED]> wrote:
> Hi all!
>
> I have a problem to get _all_ images from flac file.
> I have flac file with 3 images inside ( FLAC__METADATA_TYPE_PICTURE )
>
> How to get _all_ images with bool FLAC::Metadata::get_picture() func?
>
> This function is wrapper FLAC__bool FLAC__metadata_get_picture().
>
> flac-1.2.1/src/libFLAC/metadata_iterators.c:
> ...
> 285 FLAC_API FLAC__bool FLAC__metadata_get_picture(const char
> *filename,
> FLAC__StreamMetadata **picture, FLAC__StreamMetadata_Picture_Type
> type,
> const char *mime_type, const FLAC__byte *description, unsigned
> max_width, unsigned max_height, unsigned max_depth, unsigned
> max_colors)
> 286 {
> 287 FLAC__Metadata_SimpleIterator *it;
> 288 FLAC__uint64 max_area_seen = 0;
> 289 FLAC__uint64 max_depth_seen = 0;
> 290
> 291 FLAC__ASSERT(0 != filename);
> 292 FLAC__ASSERT(0 != picture);
> 293
> 294 *picture = 0;
> 295
> 296 it = FLAC__metadata_simple_iterator_new();
> 297 if(0 == it)
> 298 return false;
> 299 if(!FLAC__metadata_simple_iterator_init(it, filename,
> /*read_only=*/true, /*preserve_file_stats=*/true)) {
> 300 FLAC__metadata_simple_iterator_delete(it);
> 301 return false;
> 302 }
> 303 do {
> 304 if(FLAC__metadata_simple_iterator_get_block_type(it) ==
>
> FLAC__METADATA_TYPE_PICTURE) {
> 305 FLAC__StreamMetadata *obj =
> FLAC__metadata_simple_iterator_get_block(it);
> 306 FLAC__uint64 area =
> (FLAC__uint64)obj->data.picture.width *
> (FLAC__uint64)obj->data.picture.height;
> 307 /* check constraints */
> 308 if(
> 309 (type ==
> (FLAC__StreamMetadata_Picture_Type)(-1)
> || type == obj->data.picture.type) &&
> 310 (mime_type == 0 || !strcmp(mime_type,
> obj->data.picture.mime_type)) &&
> 311 (description == 0 || !strcmp((const char
> *)description, (const char *)obj->data.picture.description)) &&
> 312 obj->data.picture.width <= max_width &&
> 313 obj->data.picture.height <= max_height &&
> 314 obj->data.picture.depth <= max_depth &&
> 315 obj->data.picture.colors <= max_colors &&
> 316 (area > max_area_seen || (area == max_area_seen
> &&
> obj->data.picture.depth > max_depth_seen))
> 317 ) {
> 318 if(*picture)
> 319 FLAC__metadata_object_delete(*picture);
> 320 *picture = obj; // <--- HERE
> 321 max_area_seen = area;
> 322 max_depth_seen = obj->data.picture.depth;
> 323 }
> 324 else {
> 325 FLAC__metadata_object_delete(obj);
> 326 }
> 327 }
> 328 } while(FLAC__metadata_simple_iterator_next(it));
> 329
> 330 FLAC__metadata_simple_iterator_delete(it);
> 331
> 332 return (0 != *picture);
> 333 }
> ...
>
> In line 320 picture always overwrite in do { } ... while ( ) cycle.
> So it means, that every time I will get only the last image from
> file.
> Am I right?
>
> So how to get all images?
> Thanks for any help.
>
> Bests,
>
> ___
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Virus in FLAC Windows installer
--- Victor Koechli <[EMAIL PROTECTED]> wrote: > Just to let you know: > > The FLAC-Installer (downloadable from sourceforge) contains a > W32/Backdoor2.AAKG virus, and so does the included uninstaller. Is > this an error of my virus scanner, or did a virus indeed creep in? can someone else verify this? I know there have been false positives from some AV tools from time to time; usually they are fixed in the next virus definition. the current flac installer is 7 months old and this is the first I've heard about it. Josh Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Testing my Flac x64 build
--- Markus Ewald <[EMAIL PROTECTED]> wrote: > Now the funny part: to verify that my x64 build doesn't do anything > fishy, I ran both my self-built x86 and my x64 encoder on a test > song. > The files ended up different. Just out of fun, I downloaded the > official > Win32 command line encoder and -- its output matched 100% with the > x64 > build! So it's actually my x86 encoder that's doing something > different. that's not necessarily a problem. due to floating point differences between architectures, two builds can generate different but correct flac files. if they test with '-t' then they're fine. Josh Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] compression
--- Harry Sack <[EMAIL PROTECTED]> wrote: > hi > > can we expect much better compression (like the step to v. 1.2.x) in > future versions of the flac encoder or are we at maximum compression > level now? I touch on that here: http://www.hydrogenaudio.org/forums/index.php?showtopic=61465 Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC__HAS_OGG
--- Hardik Shah <[EMAIL PROTECTED]> wrote: > Hello, > > Can anybody tell me where FLAC__HAS_OGG is defined? it's automatically set (#define or #undef) in config.h when you run configure Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC seeking error
--- "Barra, Jay F Ctr AFRL/RIEC" <[EMAIL PROTECTED]> wrote: > I am writing a FLAC encoder/decoder and when I use the > flac_static.lib > that was compiled in debug mode in MS Visual Studio 2003, the > seek_absolute function works fine. However, if I compile flac_static > in > release mode in the same environment, the seek_absolute function no > longer works. No parts of my code change, the only difference is > whether I link in the release lib instead of the debug lib. I just > recompiled the whole of a new copy of the FLAC source code so I know > I > have the most recent FLAC source. I am compiling using MS Visual > studio > 2003 and writing in C++ but mainly using the C library and not the > C++ > library of FLAC. I'd be helpful of any hints as to which direction > to move in to solve this. I've had a report from someone else about this but I don't have any idea why. you could try the precompiled ones I make with vc6. those static release libs are linked in to the command-line tools I distribute and have not had any such problems. http://downloads.sourceforge.net/flac/flac-1.2.1-devel-win.zip Josh Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] wav to flac corruption
--- Justin Waddell <[EMAIL PROTECTED]> wrote: > I have exactly the same problem. > > I encoded a BWF file to flac and then then decoded back to wav, using > --keep-foreign-metadata, and I ended up with a bit-perfect copy of > the original BWF. So I was fairly confident that the flac encoding is > working correctly, the problem definitely appears to be with the flac > players. > > Unfortunately it seems that the majority of flac players cannot play > 24bit files - winamp, windows media player (with flac plugin), vlc, > amarok, kaffeine and a few others ALL failed to play the file. I > would > either get silence, static, or a complete refusal to play the file. > The only player that played it successfully was Foobar 2000 on > Windows. > > More seriously from my point of view is the Java flac plugin also > fails, which has major repercussions for the project I work on (the > National Archives of Australia Xena project - > http://xena.sourceforge.net). > > I don't know how much the flac developers have to do with the player > implementations, but this does seem to be a major problem across > almost the full board of flac players. this is probably the problem: http://www.hydrogenaudio.org/forums/index.php?showtopic=57572&st=40&p=518661&#entry518661 Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] In which release did FLAC support 192kHz sample rate?
--- le Chameleon <[EMAIL PROTECTED]> wrote: > Greetings, > > In reviewing the changelogs its unclear in which release FLAC began > supporting a sample rate of 192kHz. flac has always supported 192kHz. it was not in the subset until 1.2.0; before that you had to use the --lax option to encode 192kHz, which was explained in the error message since flac 1.1.1 Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC bug affecting replay-gain
--- Martin Changer <[EMAIL PROTECTED]> wrote: > Dear developer, > > According to the list of bugs on the FLAC website, --replay-gain > switch is affected > > Here's the link - > http://flac.sourceforge.net/documentation_bugs.html > > My question: Is the command "metaflac --add-replay-gain" affected > by this same bug? no, just flac. Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] WHAT IS WRONG!
--- matthew king <[EMAIL PROTECTED]> wrote: > Hi I need major help I have been able to download Flac Frontend on > every computer I have ever used EXCEPT OUR NEW ONE!!! The download > seems to go OK and then when i transfer flac files to it and click > decode a box pops up that says "Run Time\Error 75" WHAT IS THIS > !?!?!?!?!? http://flac.sourceforge.net/faq.html#tools__runtime75 p.s. sorry for the delay, you need to subscribe to the list to post. Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] cross-compile problems
--- Karl Håkansson <[EMAIL PROTECTED]> wrote: > Hi, > I've successfully compiled flac-1.1.2 to transcode flac to wav with > twonkyvision running on a DNS-323 which has a ARM-processor. The > problem is that from time to time something hangs. Therefore I have > tried to compile the newest flac, flac-1.2.1, and it compiles with no > problems but when running it, for example "flac -t test.flac", it > only echos "Illegal instruction". Is there any way to expand error > messages from flac ? that message is not coming from flac, I think the cpu hit a bytecode that is not supported by your architecture. arm has a lot of flavors. the problem probably happened somewhere during cross-compilation where the target flavor was set. Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] xmms-flac security update breaks XMMS' flac-playing ability
that missing symbol appears only in libFLAC 1.2.1 or later, so it sounds like the version dependencies in xmms-flac were not set up to automatically pull in 1.2.1. check the versions of the other flac packages on the machine (not sure what they're called in ubuntu but probably flac or libflac) and make sure they're up to 1.2.1 --- Myke Carter <[EMAIL PROTECTED]> wrote: > Hello, > > First post to this group. I've been searching for about a week now > to > find anyone who can solve this problem or point me to the solution. > > I've been a happy xmms-flac user for 4 years until this week when > some > new FLAC security updates came along and completely stopped XMMS from > playing FLACs on my PC. This is most irritating as I have over 3,500 > CDs ripped and FLAC'd in my personal music library. > > Whenever I run xmms via bash, this is what I see: > > Gtk-WARNING **: Unable to locate loadable module in module_path: > "libpixmap.so", > /usr/lib/xmms/Input/libxmms-flac.so: undefined symbol: > safe_malloc_mul_2op_ > > What is the fix for this? > > I use an Ubuntu variant called Linux Mint 2.2. > > Thanks, > Myke Get easy, one-click access to your favorites. Make Yahoo! your homepage. http://www.yahoo.com/r/hs ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC for VisualDSP
--- Matteo Montani <[EMAIL PROTECTED]> wrote: > Hi everybody, > > I need like to port the flac encoding and decoding algorithm on the > VisualDSP platform. > Do you know if it's already existing a flac version for that? > > I'm trying to estimate the computational cost of FLAClib on blackfin. > Do you know some profiling information for blackfin? > I saw the assembler code for CPU dependent optimiziations. Is there > something similar for blackfin? > I couldn't find it. I've corresponded with someone about their blackfin implementation but it may be proprietary. I don't have any info about the computational cost. it would be nice to have blackfin-specific optimizations in the official project sources though. Josh __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: Fwd: Re: [Flac-dev] FLAC for "ARM little endian for glibc"
--- bastian block <[EMAIL PROTECTED]> wrote: > On Thursday 04 October 2007 04:27:47 you wrote: > > Sir, you need to provide more information. What kind of errors? > What > > is not working? What exactly are you trying to do? What compiler > are > > you using? > > H IV0, > we are using a lot of different cross-compiler (mainly based on GCC > 3.4.x) > When I tried to cross-compile FLAC for non-i386 platforms (such as > ARM), I use > use "configure" in the following way: > > (cd ~/UPnPTVStack/lgpl-code/flac-1.1.2; make > distclean; ./configure --host=armv5b-softfloat-linux --disable-shared > > CC=/opt/crosstool/gcc-3.4.1-glibc-2.2.5/armv5b-softfloat-linux/bin/armv5b-softfloat-linux-gcc > > CXX=/opt/crosstool/gcc-3.4.1-glibc-2.2.5/armv5b-softfloat-linux/bin/armv5b-softfloat-linux-g++ > > LDFLAGS=-lpthread --without-XMMS --without-ogg ; make) > > Although I did not get any errors here, the target is not compilable, > see > attachment. > It seems that I could not get rid of dependencies from ogg and other > libraries. > Is there any standadized way for cross-compiling FLAC standalone? for no ogg, you need --disable-ogg, try ./configure --help to see all options __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] creating flacs over 2GB
--- Gyürki István <[EMAIL PROTECTED]> wrote: > Hello All, > > I was struggling with the need of creating flac files over 2GB > recently. > Both the command line flac and my util using stream encoder returned > FLAC__STREAM_ENCODER_CLIENT_ERROR when reaching that point. > > Finally I made a small change in libFLAC/stream_encoder.c in > file_tell_callback_ function. > I replaced the ftello call to fgetpos. This seems to work very well > under win32. > > Based on the description at > http://www.gnu.org/software/libc/manual/html_node/Portable-Positioning.html > I think this should be also portable solution. > > Hope this small change could help other users, too. the 2GB limit should only be a problem on windows with msvc. thanks for the tip, I will look into fgetpos for that case, hopefully it will work with msvc6 which is what I compile the releases with. Josh Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Support .cda as input files
--- David Collett <[EMAIL PROTECTED]> wrote: > Yes, this is a challenge. I am the author of mp3fs, and a major > challenge was to predict final file size accurately. This is why > mp3fs > only supports CBR mp3 and not VBR mp3 or ogg (which is inherently > VBR). > Is there a 'CBR' flac encoding mechanism? unfortunately no, lossless is also inherently VBR. Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! http://tv.yahoo.com/collections/3658 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] upcoming release, need help
thanks everyone for the feedback, the cvs tag is down and the release is almost ready. FLAC_RELEASE_1_2_1__2007_09_17 Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] general question
--- Harry Sack <[EMAIL PROTECTED]> wrote: > hi > > is it true flac began on *nix systems and development is still being > done on that platform because i never read things about windows > compilers on the mailing list? yes, I usually don't do much on windows until release time to get it compiling again with msvc. that's when you see all the windows mails. this time was not much trouble. Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] compiling win32 version
--- Harry Sack <[EMAIL PROTECTED]> wrote: > hi > > what compiler is used to compile the flac.exe in the installer: > visual studio or a gcc cross-platform compiler? that one's built with msvc6 Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] upcoming release, need help
the those logs look fine, maybe some other test failed like the unit tests which are unfortunately not logged. could you try running them individually and see if there's a problem (they're relatively quick) $ cd test $ ./test_libFLAC.sh release && ./test_libFLAC++.sh release && ./test_flac.sh release && ./test_metaflac.sh release && ./test_seeking.sh release that will stop on the first error --- Avuton Olrich <[EMAIL PROTECTED]> wrote: > On 9/14/07, Josh Coalson <[EMAIL PROTECTED]> wrote: > > checked in to CVS is what will be very close to the 1.2.1 release > > of flac scheduled for monday. if anyone can try building it and > > even better running the test suite, and reporting back any > problems, > > that will help me get things in better shape. > > Checked 2 x86_64 boxes they worked fine, 1 x86 failed a test. Logs > (streams, picture, cuesheet) for the failed box attached, please let > me know if I can help in any way. > -- > avuton > -- > Anyone who quotes me in their sig is an idiot. -- Rusty Russell. > Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV. http://tv.yahoo.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Testing 24-bit full-scale deflection streams fails
--- Daniel Aleksandersen <[EMAIL PROTECTED]> wrote: > Hi list, > > I am trying to compile and install flac 1.2. I $ ./configure(d) and $ > > make(d) without any errors or warnings. However I get the following > error > when $ make check(ing): > > > Testing 24-bit full-scale deflection streams... > > fsd24-01 (--channels=1 --bps=24 -0 -l 16 --lax -m -e -p): > encode...ERROR > > during encode of fsd24-01 > > FAIL: ./test_streams.sh > > === > > 2 of 7 tests failed > > === > > Using KUbuntu 7.04 x86_64 using following command: > $ ./configure && make && make check && sudo make install > (Which by the way works perfectly on flac 1.1.4.) > > Let me know what other data is required to find out why it failed. > And please do explain how I get that data/output/logs/whatever. test_streams.sh makes a huge file called streams.log with a record of everything. if you can snip the last 100 lines or so of it (enough to capture the entire encode/decode/verify cycle of the last test) I might be able to tell what happened. also can you verify that the md5sum of fsd24-01.raw is 5a97c581700d975fcff78e8be0f19d7e thanks, Josh Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! http://tv.yahoo.com/collections/3658 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] upcoming release, need help
--- Ralph Giles <[EMAIL PROTECTED]> wrote: > On Fri, Sep 14, 2007 at 02:51:34PM -0700, Josh Coalson wrote: > > > checked in to CVS is what will be very close to the 1.2.1 release > > of flac scheduled for monday. if anyone can try building it and > > even better running the test suite, and reporting back any > problems, > > that will help me get things in better shape. > > config.rpath seems to be missing from the repository? yeah, I'm not sure how to handle that... I thought it normally comes from gettextize. flac uses iconv but not gettext and it's not set up to run gettextize, so I've been just copying my /usr/share/gettext/config.rpath into the releases. but since it felt like a hack I never checked it in. (I did add a note in autogen.sh about it.) Josh Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos. http://autos.yahoo.com/index.html ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] upcoming release, need help
I've decided to put that one off till after the release. btw the cvs logs show that change happened between 1.1.2 and 1.1.3, or do you mean the warnings will come from the extra -W options you proposed? --- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Josh Coalson wrote: > > > checked in to CVS is what will be very close to the 1.2.1 release > > of flac scheduled for monday. if anyone can try building it and > > even better running the test suite, and reporting back any > problems, > > that will help me get things in better shape. > > I'm currently running the tests on : > > Linux x86-64 > Mac OSX PowerPC > > Do you plan to revert the changes you made to the function > prototypes: > > FLAC__metadata_object_picture_set_mime_type > FLAC__metadata_object_picture_set_description > > in include/FLAC/metadata.h? Like I stated in a previous email: > > http://lists.xiph.org/pipermail/flac-dev/2007-September/002351.html > > If you allow this changes to stay, it will mean that client code > that compiled with no warnings with FLAC 1.2.0 will produce > warnings with 1.2.1. > > > Erik Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV. http://tv.yahoo.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] upcoming release, need help
--- Avuton Olrich <[EMAIL PROTECTED]> wrote: > On 9/14/07, Josh Coalson <[EMAIL PROTECTED]> wrote: > > checked in to CVS is what will be very close to the 1.2.1 release > > of flac scheduled for monday. if anyone can try building it and > > even better running the test suite, and reporting back any > problems, > > that will help me get things in better shape. > > > > changelog: > > > http://flac.cvs.sourceforge.net/*checkout*/flac/flac/doc/html/changelog.html?revision=HEAD > > I'd love to, I've got CVS checked out, how do I run this test suite? from the top level this should work: ./autogen.sh && make && make check the last part runs the tests. there are a lot of them so if it's really taking too long, you can rerun configure with --disable-thorough-tests and do 'make check' again. Josh Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] upcoming release, need help
checked in to CVS is what will be very close to the 1.2.1 release of flac scheduled for monday. if anyone can try building it and even better running the test suite, and reporting back any problems, that will help me get things in better shape. changelog: http://flac.cvs.sourceforge.net/*checkout*/flac/flac/doc/html/changelog.html?revision=HEAD TIA, Josh Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Support .cda as input files
--- Daniel Aleksandersen <[EMAIL PROTECTED]> wrote: > Hi list, > > I would really like to see support for .cda as input files. The cda > format is the one used on regular audio CDs. if the .cda files appeared as regular files in the filesystem and implemented enough of the POSIX stream interface, it is possible, but I don't know the what the format of the data is. otherwise, it really doesn't belong in flac but in a ripping program. you're the first one to ask though, probably because people using FLAC also tend to care about rip quality and the .cda scheme would almost have to use burst mode to present a regular file interface. Josh Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Two GCC warnings flags you should enable ASAP
I'll add these, I think they didn't get in with your previous patch because I withheld a part of it for some other reason... --- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Josh, > > There are two GCC warning flags you should enable for all the > C code ASAP. From the gcc man page: > > -Wmissing-prototypes (C only) > Warn if a global function is defined without a previous prototype > declaration. This warning is issued even if the definition > itself > provides a prototype. The aim is to detect global functions that > > fail to be declared in header files. > > -Wstrict-prototypes (C only) > Warn if a function is declared or defined without specifying the > argument types. (An old-style function definition is permitted > without a warning if preceded by a declaration which specifies > the > argument types.) > > Currently in the file src/share/utf8/charset.c you use the new > allocation > functions without including "include/share/alloc.h". The first > warning > flag above would catch this issue. The second warning flag will catch > things like old-style K&R function definitions which were obsoleted > by the 18 year old 1989 C standard :-). > > These two warning flags have been available at least since gcc-2.95. > All the 3 and 4 series gcc compilers accept them. > > Cheers, > Erik > -- > - > Erik de Castro Lopo > - > "When exported to Muslim lands, various aspects of Western pop > culture must be modified in order to accommodate Muslim > sensibilities. > When Muslims come West, various aspects of Western pop culture must > be modified in order to accommodate Muslim sensibilities." > -- http://www.jihadwatch.org/dhimmiwatch/archives/008623.php > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] [PATCH] Fix errors in new Makefile.ams
fixed, thanks. --- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Josh, > > The two Makefile.ams that you added recently: > > examples/c/decode/file/Makefile.am > examples/cpp/decode/file/Makefile.am > > are generating errors like this: > > examples/c/decode/file/Makefile.am:22: blank line following > trailing backslash > examples/cpp/decode/file/Makefile.am:22: blank line following > trailing backslash > > The attached patch fixes these. > > Erik > -- > - > Erik de Castro Lopo > - > "I'd crawl over an acre of 'Visual This++' and 'Integrated > Development That' to get to gcc, Emacs, and gdb. Thank you." > -- Vance Petree > > Index: examples/c/decode/file/Makefile.am > === > RCS file: /cvsroot/flac/flac/examples/c/decode/file/Makefile.am,v > retrieving revision 1.2 > diff -u -r1.2 Makefile.am > --- examples/c/decode/file/Makefile.am12 Sep 2007 05:34:51 - > 1.2 > +++ examples/c/decode/file/Makefile.am12 Sep 2007 09:39:54 - > @@ -18,7 +18,7 @@ > EXTRA_DIST = \ > Makefile.lite \ > example_c_decode_file.dsp \ > - example_c_decode_file.vcproj \ > + example_c_decode_file.vcproj > > noinst_PROGRAMS = example_c_decode_file > example_c_decode_file_LDADD = \ > Index: examples/cpp/decode/file/Makefile.am > === > RCS file: /cvsroot/flac/flac/examples/cpp/decode/file/Makefile.am,v > retrieving revision 1.1 > diff -u -r1.1 Makefile.am > --- examples/cpp/decode/file/Makefile.am 12 Sep 2007 05:27:34 - > 1.1 > +++ examples/cpp/decode/file/Makefile.am 12 Sep 2007 09:39:54 - > @@ -18,7 +18,7 @@ > EXTRA_DIST = \ > Makefile.lite \ > example_cpp_decode_file.dsp \ > - example_cpp_decode_file.vcproj \ > + example_cpp_decode_file.vcproj > > noinst_PROGRAMS = example_cpp_decode_file > example_cpp_decode_file_LDADD = \ > Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! http://tv.yahoo.com/collections/3658 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] include/share/alloc.h
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote:
> Josh,
>
> I noticed the recent addition of the above file. In that file you
> have
> things like:
>
> static void *safe_malloc_(size_t size)
> {
> /* malloc(0) is undefined; FLAC src convention is to always
> allocate */
> if(!size)
> size++;
> return malloc(size);
> }
>
> Did you meant to have an "inline" in there to make it:
>
> static inline void *safe_malloc_(size_t size)
>
> By making them static functions, it means that (in C at least, not
> sure
> about C++) every object file gets a copy of these functions whether
> they
> are used or not. It also results in a bunch of warning messages like:
>
> ../../include/share/alloc.h:51: warning: 'safe_calloc_' defined
> but not used
> ../../include/share/alloc.h:68: warning: 'safe_malloc_add_3op_'
> defined but not used
> ../../include/share/alloc.h:79: warning: 'safe_malloc_add_4op_'
> defined but not used
> ../../include/share/alloc.h:115: warning: 'safe_malloc_mul_3op_'
> defined but not used
> ../../include/share/alloc.h:128: warning: 'safe_malloc_mul2add_'
> defined but not used
> ../../include/share/alloc.h:138: warning: 'safe_malloc_muladd2_'
> defined but not used
> ../../include/share/alloc.h:148: warning: 'safe_realloc_add_2op_'
> defined but not used
> ../../include/share/alloc.h:156: warning: 'safe_realloc_add_3op_'
> defined but not used
> ../../include/share/alloc.h:167: warning: 'safe_realloc_add_4op_'
> defined but not used
>
> In C (certainly C99, probably also C89) functions that that are
> defined
> "static inline" are inlined if used and ignored (ie no warnings) if
> not used.
>
> Is this stuff still a work in progress?
yes. I would use inline except I thought it is only since C99 (not
available in C89), so I'm planning to do the same odious hackery
that's everywhere else.
Pinpoint customers who are looking for what you sell.
http://searchmarketing.yahoo.com/
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Is FLAC__stream_decoder_seek_absolute working for OggFlac?
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Josh Coalson wrote: > > > > The test file is here: > > > > > > http://www.mega-nerd.com/tmp/flac_char.ogg > > > > yep, this is definitely a bug, thanks for the test case. requires > > a tiny fix to the ogg seek algorithm which I will check in tonight. > > Oh cool. I was wondering what happened to that issue. ok, checked in the fix to cvs. Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Is FLAC__stream_decoder_seek_absolute working for OggFlac?
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Josh Coalson wrote: > > > --- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > > > > > Hi all, > > > > > > Is seeking working for OggFlac files? I keep on getting a > > > FLAC__STREAM_DECODER_SEEK_ERROR. > > > > yes, it should work fine. in flac/src/test_seeking/main.c there > > is an example usage of FLAC__stream_decoder_seek_absolute(). you > > could try compiling it and running test_seeking on it. if if fails > > maybe there is a bug that your stream is triggering. > > Ok, running the command: > > src/test_seeking/test_seeking flac_char.ogg > > resulted in: > > +++ seek test: FLAC__StreamDecoder (Ogg FLAC, read_mode=0) > > file's total_samples is 0 > Begin seek barrage, count=0 > #0:seek(0)... seek failed, assuming it was past EOF... OK > #1:seek(1)... seek failed, assuming it was past EOF... OK > #2:seek(2)... seek failed, assuming it was past EOF... OK > #3:seek(3)... seek failed, assuming it was past EOF... OK > #4:seek(4)... seek failed, assuming it was past EOF... OK > #5:seek(5)... seek failed, assuming it was past EOF... OK > #6:seek(6)... seek failed, assuming it was past EOF... OK > #7:seek(7)... seek failed, assuming it was past EOF... OK > #8:seek(8)... seek failed, assuming it was past EOF... OK > #9:seek(9)... seek failed, assuming it was past EOF... OK > #10:seek(2332)... seek failed, assuming it was past EOF... OK > #11:seek(2331)... seek failed, assuming it was past EOF... OK > #12:seek(2330)... seek failed, assuming it was past EOF... OK > #13:seek(2329)... seek failed, assuming it was past EOF... OK > > and so on. > > The test file is here: > > http://www.mega-nerd.com/tmp/flac_char.ogg yep, this is definitely a bug, thanks for the test case. requires a tiny fix to the ogg seek algorithm which I will check in tonight. Josh Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Warnings with automake-1.10
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Josh, > > Automake 1.10 on OSX is giving me warnings like the following: > > test/Makefile.am:50: wildcard *.raw: non-POSIX variable name > test/Makefile.am:50: (probably a GNU make extension) > test/Makefile.am:50: wildcard *.flac: non-POSIX variable name > test/Makefile.am:50: (probably a GNU make extension) > test/Makefile.am:50: wildcard *.oga: non-POSIX variable name > test/Makefile.am:50: (probably a GNU make extension) > > which is complaining about things like this: > > CLEANFILES = \ > $(wildcard *.raw) \ > $(wildcard *.flac) \ > $(wildcard *.oga) \ > $(wildcard *.ogg) \ > $(wildcard *.cmp) \ > $(wildcard *.aiff) \ > > I did some research: > > http://www.cygwin.com/ml/automake/2000-07/msg00013.html > > http://www.gnu.org/software/automake/manual/html_node/wildcards.html > > http://www.gnu.org/software/automake/manual/automake.html#index-clean_002dlocal-737 > > and it seems that the correct way to do what you want is: > > clean-local: > -rm -f *.raw *.flac *.oga *.ogg *.cmp *.aiff > > Do you want to do this or should I send a patch? thanks, I'll do it. got automake-1.10 on one of my boxes now so I'll go through the whole thing tonight to make sure it's working. Josh Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! http://tv.yahoo.com/collections/3658 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] [PATCH] autogen.sh : detect automake-1.10 correctly
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Josh, > > Macports on OSX ships with automake-1.10 and the current autogen.sh > detects 1.10 as an invalid version of automake. > > The following patch (snarfed from autogen.sh from libvorbis) fixes > that. fixed in cvs (I think, I might have messed it up editing the inline patch from the mail, attachments work better) Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Compile problems on OSX
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Sorry, I just updated from CVS and its still broken. If FLAC__HAS_OGG > is false it tries to compile this: > > (void)decode_options; > > and there is no "decode_options" identifier. oops, fixed. Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545433 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC__FrameHeader's blocksize element
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Hi all, > > I've found that the FLAC__FrameHeader struct's blocksize member > has values limited to the range (0, FLAC__MAX_BLOCK_SIZE] where > FLAC__MAX_BLOCK_SIZE is 65535. > > In the encoder, what determines the size of a block? in libFLAC, currently the client dictates the block size which is used for all blocks in the stream. Josh Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Compile problems on OSX
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I've got two problems compiling the current CVS FLAC sources on OSX.
>
> Firstly, the configure script can't find the OGG libraries which were
> installed from MacPorts. I have tried:
>
> ./configure --with-ogg-includes=/opt/local/include \
>--with-ogg-lib=/opt/local/lib
>
> but they are still not found. I notice that in configure.in, you use
> a macro called XIPH_PATH_OGG. Is there any reason you don't use the
> PKG_CHECK_MODULES mcaro which uses pkg-config underneath? For my
> system pkg-config does the right thing:
>
> > pkg-config --cflags --libs ogg
> -I/opt/local/include -L/opt/local/lib -logg
>
> I will put together a patch for this is you are interested.
the main reason I haven't swtiched is I'm not up on pkgconfig
and XIPTH_PATH_OGG has been working pretty well... can you tell
why it's not working for you?
I'm always hesitant to mess with things in configure.in because
is such whack-a-mole problem (fixes things for some people and
breaks for others).
> Second problem is that I get a compile error when FLAC__HAS_OGG is 0
> in src/flac/decode.c:
>
> decode.c:393: error: 'options' undeclared (first use in this
> function)
>
> The code in question is this:
>
> #if FLAC__HAS_OGG
> if(decoder_session->is_ogg) {
> /* Some code here. */
> }
> else
> #else
> (void)decode_options;
> #endif
> {
> /* More code. */
> }
yes, this is fixed in cvs. actually I'll probably be doing a
release soon and I'd be interested to know if the latest stuff
works for you.
> The problem here is that conditional compiles can hide bugs. The code
> above
> re-written to turn a conditional compile into an always compiled if
> statement
> which will trigger the error regardless of the value of
> FLAC__HAS_OGG:
>
> if(FLAC__HAS_OGG && decoder_session->is_ogg) {
> /* Some code here. */
> }
> else
> {
> (void)decode_options;
> /* More code. */
> }
interesting idea, hadn't thought of that.
Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Re: multiple core support
--- Ralph Giles <[EMAIL PROTECTED]> wrote: > On Fri, Sep 07, 2007 at 04:59:50PM -0700, Josh Coalson wrote: > > > it actually is complicated. the libFLAC api is not suited to a > > multithreaded design because the i/o is stream-based, not file- > > based. flac(.exe) is the file-based wrapper around libFLAC that > > allows it to work on files. the way libFLAC buffers data is also > > impossible to parallelize without significantly changing the api. > > It seems like buffering (especially compressed) blocks and writing > them > to the stream in sequence wouldn't be a problem. Is there something > in > the way the blocking decisions are made that makes it hard to divide > the > input audio this way? if the constraint of sequential output is kept, I was thinking that to get maximum efficiency, the library would need to be able to get samples out of order to keep all the threads going at max speed, or might have to grow buffers arbitrarily large if fed samples sequentially because of the different processing requirements of different blocks. extreme example: a block that goes through high- order LPC processing followed by several silence or noise blocks. Josh Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Re: multiple core support
--- Harry Sack <[EMAIL PROTECTED]> wrote: > 2007/9/8, Josh Coalson <[EMAIL PROTECTED]>: > > > > it actually is complicated. the libFLAC api is not suited to a > > multithreaded design because the i/o is stream-based, not file- > > based. flac(.exe) is the file-based wrapper around libFLAC that > > allows it to work on files. the way libFLAC buffers data is also > > impossible to parallelize without significantly changing the api. > > why was this approach used? because the tradeoffs I described required for arbitrarily parallel encoding significantly complicate the api and implementation. libFLAC was not design for multicode file encoding on PCs, it is a reference design that is also being used in embedded devices running <100MHz, low memory, all kinds of different OSes, etc. > The API design seems to me not very smart > because it's not flexible and you're stuck in the future (like now > for multiple core support) > > I don't see any reason why you wouldn't make it all based on files > and not on streams :s It's just a major disavantage in my opinion an api cannot be all things to everyone. you keep making this assertion but if you actually tried to implement it (and I hope you will) the problems we are all bringing up will quickly become obvious. your own lame-mt example is not an incremental improvement but a significant rewrite of lame (and also does not have nearly the performance advantage of process-level parallelism, see http://www.hydrogenaudio.org/forums/index.php?showtopic=50862) > > it would take a specialty file-based encoder using an independent > > frame encoder to do and even that is not trivial. > > so we can assume that those API changes will never come and the flac > encoder will never have multiple core support? you can assume libFLAC will probably not have it. if you can modify libFLAC to make a multithreaded encoder like flac-mt that would be neat and probably useful to some people. until that time there is not much point repeating the same assertions which are just going to aggravate people. Josh Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Re: multiple core support
it actually is complicated. the libFLAC api is not suited to a multithreaded design because the i/o is stream-based, not file- based. flac(.exe) is the file-based wrapper around libFLAC that allows it to work on files. the way libFLAC buffers data is also impossible to parallelize without significantly changing the api. it would take a specialty file-based encoder using an independent frame encoder to do and even that is not trivial. --- Harry Sack <[EMAIL PROTECTED]> wrote: > 2007/9/7, Avuton Olrich <[EMAIL PROTECTED]>: > > > > On 9/6/07, Harry Sack <[EMAIL PROTECTED]> wrote: > > > it's really not complicated I think: only api changes to write on > any > > > > Please get started writing a patch, immediately. > > > > I'm just an IT student and I have no time for that :) > I also didn't study the flac API in detail but I know it's perfectly > possible because I made a avi encoder running on multiple threads > once and > it's exactly the same for audio data. > > -- > > avuton > > -- > > Anyone who quotes me in their sig is an idiot. -- Rusty Russell. > > > > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Re: 1.2.0: Test suite failures on LP64 archs?
thanks, I had fixed that same problem in nearby functions but
somehow missed that one...
--- Christian Weisgerber <[EMAIL PROTECTED]> wrote:
> Christian Weisgerber <[EMAIL PROTECTED]> wrote:
>
> > The bug was introduced in 1.2.0 with the fully unrolled functions
> > in libFLAC/lpc.c.
>
> I guess the use of unsigned index variables was an accident.
> Changing
> them back to int makes FLAC pass the "thorough" test suite on amd64.
>
> --- src/libFLAC/lpc.c.origSun Sep 2 00:13:36 2007
> +++ src/libFLAC/lpc.c Sun Sep 2 00:14:01 2007
> @@ -569,7 +569,7 @@ void
> FLAC__lpc_compute_residual_from_qlp_coefficients_
> }
> #else /* fully unrolled version for normal use */
> {
> - unsigned i;
> + int i;
> FLAC__int64 sum;
>
> FLAC__ASSERT(order > 0);
> @@ -1099,7 +1099,7 @@ void FLAC__lpc_restore_signal_wide(const
> FLAC__int32 r
> }
> #else /* fully unrolled version for normal use */
> {
> - unsigned i;
> + int i;
> FLAC__int64 sum;
>
> FLAC__ASSERT(order > 0);
> --
> Christian "naddy" Weisgerber
> [EMAIL PROTECTED]
> ___
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links.
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] application/flac vs. audio/flac
--- Ivo Emanuel Gonçalves <[EMAIL PROTECTED]> wrote: > Ralph reports: > > "I believe application/flac was used in analogy to application/ogg, > and has never actually be registered. This might be an opportunity to > register the more correct audio/flac. I don't know if an informational > RFC on the flac format needs to be published for that to happen." > > What do you think, Josh? I'm in the process of writing a RFC > regarding all MIME types used in the different Xiph formats, plus I'll > undertake the painful registration process at IANA, so I'd like to > hear if you would like to take this opportunity to change the above. I'm actually not sure what exactly the difference is but if you can take on the registration that would be great. I don't really know how to write an acceptable RFC but I can help fill in any needed technical details. Josh Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545433 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Donation to the FLAC development project
--- J Palermo <[EMAIL PROTECTED]> wrote: > Hi, > > I have a legitimate request for information about how I can > contribute to > the development of FLAC. I am not a developer, but would like to > make a > financial contribution. FLAC has immensely enhanced my enjoyment of > music. > Please let me know if this is an inappropriate forum for this > request. > > Please respond. > > Thank you. thanks Joe, that's very generous. I've decided that if I couldn't raise enough to be able to work on flac full-time that I would just do what I can in my free time and not try to earn anything from it. that's why I haven't signed up for sourceforge's donation system or run any ads on the site. if you're so inclined I'm sure xiph.org or sourceforge would appreciate any donation and it would go to fund the same kind of work; the flac project does benefit from xiph's and sourceforge's services. Josh Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] pcspkr wave encoding
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
> there is an interesting case when the FLAC encoder (using 1.2.0) is
> given simple waves. Simple waves means: I have a list of {frequency,
> duration, pause} tuples that define the monophonic tune. In other
> words, exactly one frequency is played at a time.
>
> This is the original dataset from 1989 (driving a PC speaker back
> then):
>
> $ ls -l ihold.sd
> -rw-r--r-- 1 jengelh users 20616 Aug 14 00:57 ihold.sd
>
> Since driving the PC speaker is mostly a privileged operation these
> days, one would just convert it to PCM and use soundcard output. The
> program "sd" I have written does just that. The two numerical
> parameters a and b denote the square and sine rate.
>
> # 0:1 rate <=> 0% square, 100% sine generation
> $ ./sd ihold.sd 0 1 | sox -r48000 -s -w -t raw - ihold-sine.wav
>
> # 1:2 rate <=> 33% square, 66% sine generation
> $ ./sd ihold.sd 1 2 | sox -r48000 -s -w -t raw -
> ihold-square1-sine2.wav
>
> # 1:0 rate <=> 100% square, 0% sine generation
> $ ./sd ihold.sd 1 0 | sox -r48000 -s -w -t raw - ihold-square.wav
>
> Now this is what happens when encoding to FLAC:
>
> $ flac -8 ihold-sine.wav
> ihold-sine.wav: wrote 245 bytes, ratio=0.353
>
> $ flac -8 ihold-sine2-square1.wav
> ihold-sine2-square1.wav: wrote 5474921 bytes, ratio=0.798
>
> $ flac -8 ihold-square.wav
> ihold-square.wav: wrote 5573016 bytes, ratio=0.813
>
> As soon as square waves are mixed in, the FLAC compression ratio
> drops rapidly up to the point where it equals the ratio of typical
> day-to-day music.
>
> While I do not request FLAC to compress the wave back to its original
> 20KB, I think it could improve on the sine and square compression.
> Are there any plans to address this?
hard to say what is happening without seeing the files. FLAC does
have a run-length encoding mode so with pure square waves it is
possible to get very high compression with a custom encoder.
Josh
Got a little couch potato?
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC 1.2.0 won't build without ogg
sorry about that... yep it's fixed in CVS HEAD already..
--- Christopher Key <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Apologies if this has already been covered. I'm trying to compile
> FLAC
> 1.2.0 under FreeBSD without ogg support:
>
> when I run gmake, I get:
>
> encode.c: In function `convert_to_seek_table_template':
> encode.c:2181: error: structure has no member named `use_ogg'
>
> the following appears to fix the problem for me, although I've not
> checked it fully:
>
> --- flac-1.2.0/src/flac/encode.c.oldTue Jul 10 03:10:44 2007
> +++ flac-1.2.0/src/flac/encode.cThu Aug 9 13:27:20 2007
> @@ -2178,10 +2178,15 @@
>
> if(num_requested_seek_points < 0) {
> /*@@ workaround ogg bug: too many seekpoints
> makes
> table not fit in one page */
> - if(e->use_ogg && e->total_samples_to_encode > 0 &&
> e->total_samples_to_encode / e->sample_rate / 10 > 230)
> +#if FLAC__HAS_OGG
> + if(e->use_ogg && e->total_samples_to_encode > 0 &&
> e->total_samples_to_encode / e->sample_rate / 10 > 230) {
> requested_seek_points = "230x;";
> + }
> else
> +#endif
> + {
> requested_seek_points = "10s;";
> + }
> num_requested_seek_points = 1;
> }
>
>
> Regards,
>
> Christopher Key
>
> ___
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news,
photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] lossless codecs in wireless headphones.
--- Ameya Potadar <[EMAIL PROTECTED]> wrote: > Hey, > just came across this article. > http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=ZLCZZJMVGJYNYQSNDLSCKHA?articleID=201202250 > . > Many of you would be already aware of this. It mentions flac also. i > feel it > is a good segment(stereo wireless headsets over bluetooth) to push > flac > given very light decoder and using encoder at low compression(to > reduce > complexity). Though very less is known in terms of compression and > complexity about this proprietary codec(SoundAbout Lossless codec), i > feel possibility of pitching flac as a standard for stereo-audio over > bluetooth should be explored. I saw that too. a lot of EE times articles are just regurgitated PR, which is fine I guess for trade magazines, but usually not that balanced. as you hint at, FLAC latency can be tuned down to the 2-10 msec range too, and libFLAC has encoding modes that are nearly as fast as decoding. even more is possible with a hardware implementation, but it's been a while since I wrote any HDL and don't have the spare time for it. Josh Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] building flac 1.2.0 on OS X
damn, I see the problem. there needs to be an #if FLAC__HAS_OGG
nearby, like so:
if(num_requested_seek_points < 0) {
#if FLAC__HAS_OGG
/*@@ workaround ogg bug: too many seekpoints makes table
not fit in one page */
if(e->use_ogg && e->total_samples_to_encode > 0 &&
e->total_samples_to_encode / e->sample_rate / 10 > 230)
requested_seek_points = "230x;";
else
#endif
requested_seek_points = "10s;";
num_requested_seek_points = 1;
}
--- "Scott C. Brown 02" <[EMAIL PROTECTED]> wrote:
> I just tried to build 1.2 on my Macbook
>
>
> i ran configure with the following arguments (like i have in the
> past)
>
> ./configure --enable-static --disable-asm-optimizations
> --disable-shared
>
> then "make:
>
> i get the following error:
>
> encode.c: In function 'convert_to_seek_table_template':
> encode.c:2181: error: 'struct ' has no member named
> 'use_ogg'
> make[3]: *** [encode.o] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
>
>
> Anyone know what's going on?
>
> Thanks,
> Scott
Get the free Yahoo! toolbar and rest assured with the added security of spyware
protection.
http://new.toolbar.yahoo.com/toolbar/features/norton/index.php
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC__stream_decoder_process_single and FLAC__STREAM_DECODER_END_OF_STREAM
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Hi all, > > If I have code that does this: > > while (FLAC__stream_decoder_process_single (decoder)) > /* Do something. */ ; > > I get an infinite loop. Shouldn't FLAC__stream_decoder_process_single > return false if it gets to FLAC__STREAM_DECODER_END_OF_STREAM? it supposed to be like that actually, there's a little explanation here: http://flac.sourceforge.net/api/group__flac__stream__decoder.html#ga45 Josh Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] PATCH : Fix missing protoypes
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Hi all, > > I added -Wmissing-prototypes -Wstrict-prototypes to the CFLAGS and > found that there were a number warnings generated. > > The patch below fixes those warnings and adds the two -W flags to > configure.in. I checked most of it in, though g++ 4.0.0 is giving me: cc1plus: warning: command line option "-Wmissing-prototypes" is valid for Ada/C/ObjC but not for C++ cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++ Josh Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Is FLAC__stream_decoder_seek_absolute working for OggFlac?
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Hi all, > > Is seeking working for OggFlac files? I keep on getting a > FLAC__STREAM_DECODER_SEEK_ERROR. yes, it should work fine. in flac/src/test_seeking/main.c there is an example usage of FLAC__stream_decoder_seek_absolute(). you could try compiling it and running test_seeking on it. if if fails maybe there is a bug that your stream is triggering. Josh Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] --cuesheet include the full cue sheet or just the seekponints?
--- Zhang Weiwu <[EMAIL PROTECTED]> wrote: > Dear list > > Sorry to ask a user's question on developer list. I didn't find the > user list. that's ok, it's here: http://lists.xiph.org/mailman/listinfo/flac > My guess is either cuesheet is embeded but non of my player can let > me see it, or only seekpoints (or, information about where each track > starts) is embeded in flac file? it embeds everything except the tags, see http://flac.sourceforge.net/faq.html#general__no_cuesheet_tags http://flac.sourceforge.net/documentation_tools_flac.html#flac_options_cuesheet http://flac.sourceforge.net/format.html#def_CUESHEET I think the reason it works in foobar might be that it calculates a cddb id or cdindex id from the cuesheet and looks up the metadata that way automatically. Josh Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545433 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] quick and easy way to convert id3-tagged flac to flac-tagged flac?
case's tag will do it I think http://www.synthetic-soul.co.uk/tag/ Josh --- Dan Pritts <[EMAIL PROTECTED]> wrote: > So before i knew better, i encoded a lot of my CDs in flac and added > id3 tags (they worked, so great!). > > I know i've seen mention of others doing this; anyone gone to the > trouble to write a tag conversion tool? Shouldn't be too tough, > but i'd rather not reinvent the wheel. > > danno > -- > dan pritts > [EMAIL PROTECTED] > 734-929-9770 It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] I can't use libFLAC++
libFLAC++ wraps libFLAC which also uses libogg, so to link you need something like "-lFLAC++ -lFLAC -logg" --- Leonidas Andreadis <[EMAIL PROTECTED]> wrote: > Hi, > > I've been trying to use the FLAC lib for c++. I need > to implement basic encoder function in my application, > so i tried to include encoder.h , set everything to > the default path, and included > stream_encoder.cpp,stream encoder.cpp files in the > project. Include is > > #include "FLAC++/encoder.h" > > i write something like this > > FLAC::Encoder::File test; > > i build, compile goes ok but then i get > > [Linker Error] Unresolved external > '_FLAC__stream_encoder_set_ogg_serial_number' > referenced from H:\FLAC VISUAL\PIGEOS > KODIKAS\STREAM_ENCODER.OBJ > [Linker Error] Unresolved external > '_FLAC__stream_encoder_set_bits_per_sample' referenced > from H:\FLAC VISUAL\PIGEOS KODIKAS\STREAM_ENCODER.OBJ > > and a lot of other similar linker errors. > > Am i doing it wrong? Should i follow instructions in > Readme to build the library? > > Thanks Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] flac recipe for magicrescue
--- Richard Zidlicky <[EMAIL PROTECTED]> wrote: > Hi, > > I have cooked up a simple flac recipe for magicrescue - seems > to work fine. Any ideas for improvement? Is there any way to > recover the original filename from the compressed data? unfortunately no, the filename is not stored. Josh Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC: library for C#
is wrapping c++ any easier? because there is libFLAC++ otherwise, if you only need a certain subset of what FLAC does it might be easier to write a smaller C interface + wrapper implementation, then import that in c#. Josh --- Pyt <[EMAIL PROTECTED]> wrote: > I tried that approach a while ago and failed miserably. Marshalling > the > structs of structs in the flac lib turned out to be a nightmare (I > don't > pretend to be an expert, mind you...). > I eventually switched to writing my own C# lib from scratch. Work is > still > under progress. It's no rocket science, I do this a G-job. It has > definite > limitations (no documentation, decodes only 16-bit files, no encode, > *much* > slower than the flac reference implementation, but still reasonable > for what > I do), but it can read and write metadata. It still needs a bit of > polishing > (esp. the documentation to be usable), but I'd be willing to share it > at > some point. Note that it's not open source for the time being, but > that > could be considered. > > Pyt. > > PS: If anybody has a real pinvoke wrapper for the reference lib, I'd > gladly > take it... ! > > > On 6/14/07, Jud White - [EMAIL PROTECTED] <+flac- > [EMAIL PROTECTED]> wrote: > > > > Harry, > > > > DllImport is the way to go, but it's not always straightforward > what to > > do (callbacks, pointers, and structs can get tricky). > > http://pinvoke.net/ is a good resource for mapping Win32 API to C# > using > > DllImport, you may find it useful for your efforts. I also found > this > > article helpful in context of DllImport: > > http://www.vsj.co.uk/articles/display.asp?id=501. > > > > I have some C# code for working with FLAC and Vorbis Comments that > does > > not use the FLAC libraries: > > > > > http://idsharp.svn.sourceforge.net/viewvc/idsharp/IdSharp.Tagging/trunk/Tagging/VorbisComment/Classes/ > > > > > http://idsharp.svn.sourceforge.net/viewvc/idsharp/IdSharp.AudioInfo/trunk/Flac/ > > > > taglib# also handles flac > > > > Erik de Castro Lopo wrote: > > > Harry Sack wrote: > > > > > > > > >> but aren't they C++ headers en lib's? > > >> > > > > > > Not C++, C. > > > > > > > > >> I have no idea how I can include a C++ > > >> header in a C# project. > > >> It this even possible? > > >> > > > > > > Yes. Google for "dllimport csharp". > > > > > > Erik > > > > > ___ > > Flac-dev mailing list > > Flac-dev@xiph.org > > http://lists.xiph.org/mailman/listinfo/flac-dev > > > > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Patch : Fix pointer cast warning
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Josh Coalson wrote: > > > excellent, thanks for the tip. this solves the problem for > > autoconf-based builds, but still not sure how to do it for MSVC. > > Sorry, whats the problem with MSVC? how to figure out the right setting of SIZEOF_VOIDP at compile time from whatever #defines MSVC has (if possible). Josh Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Patch : Fix pointer cast warning
excellent, thanks for the tip. this solves the problem for autoconf-based builds, but still not sure how to do it for MSVC. Josh --- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Hi all, > > The code currently in CVS gives a compile warning: > > memory.c: In function 'FLAC__memory_alloc_aligned': > memory.c:52: warning: cast from pointer to integer of different size > memory.c:52: warning: cast to pointer from integer of different size > > The patch below fixes this warning by detecting the sizeof (void*) > at configure time and then using that for a little pointer > arithmetic. > > Cheers, > Erik Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Typo in aclocal.m4
--- wrote: > Hi Josh (and everyone else on the list), > > Here's a quick fix for libFLAC.m4 and libFLAC++.m4 for a problem that > crops up if you use the macros in an environment where > LD_LIBRARY_PATH > is set. The macros save LD_LIBRARY_PATH as ac_save_LDPATH, but > restore > it from ac_save_LD_LIBRARY_PATH. This patch changes ac_save_LDPATH to > ac_save_LD_LIBRARY_PATH. > > Without this, LD_LIBRARY_PATH effectively gets clobbered after using > the libflac macros. thanks, fixed in CVS The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC: library for C#
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Harry Sack wrote: > > > Hi FLAC dev's list, > > > > I'm looking for a library for the C# language (Microsoft .Net > > Framework 2.0or higher) to play FLAC files and/or maybe do some > other > > things like getting > > the file duration, file properties, ... of FLAC files. > > The library must preferably be free (open source is not required, > but is > > always nice). > > Why not just build FLAC as a DLL and then call into the DLL from C#? Harry, if that is good enough, there are already pre-build DLLs with headers in the sourceforge download section. Josh Get the Yahoo! toolbar and be alerted to new email wherever you're surfing. http://new.toolbar.yahoo.com/toolbar/features/mail/index.php ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
