Re: [flac-dev] Git branch with compiling fixes for win32
On May 7, 2012, at 06:11, Miroslav Lichvar wrote: > On Fri, May 04, 2012 at 11:22:00AM -0400, Cristian Rodríguez wrote: >> El 03/05/12 12:19, Miroslav Lichvar escribió: >>> It makes the C function faster than the corresponding asm >>> routine, so >>> if it's included I'd suggest to just drop the asm function to not >>> keep >>> around more asm code than is necessary. >> >> With current compilers it is very likely that those routines are >> already >> superflous. > > It seems the current compilers are not that good yet :). > > In a test on a Core 2 machine with gcc-4.6.3, i686 flac build with > nasm enabled is about 7% faster in decoding than without nasm. x86_64 > build is about 2% faster than the i686 build with nasm enabled. Thank you for running these benchmarks and reporting on the results, Miroslav. As a sometimes assembly coder, I believe that compilers will never be able to beat a human mind in all situations, even if they can in most. I can't speak for the FLAC assembly developers, but when I write assembly, I always check the compiler's output at all optimization settings just to be sure I'm not wasting my time. That certainly doesn't guarantee that the compiler will never improve its results, but keep in mind that changes to compilers sometimes produce less optimal results for particular cases, even if they involve improvements in most general cases. But it's certainly good to double-check periodically as compilers "improve." Brian Willoughby Sound Consulting ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
Sven-Hendrik Haase wrote: > Sooo any news? Unfortunately, my day job, my family and a bunch of other commitments have been getting in my way. I *know* I will have some free time between xmas and new year. I have no guarantees of any decent block of time showing up before that. 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
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/16/2011 07:47 PM, Erik de Castro Lopo wrote: > Avuton Olrich wrote: > >> Hello, >> >> Hate to be Capt. obvious here, but there's a lot of development going >> on here that should be encouraged. If the FLAC project isn't going to >> open up, it would make a lot of sense for someone to take over >> maintenance on a github account with the git-cvsimport or such. I >> don't see anyone stepping up, me included, but I wanted to throw this >> out there in case someone hasn't really thought about it yet. > There is a Git branch on the Xiph server here: > > http://git.xiph.org/?p=flac.git;a=summary > > When I find a little bit of time (the weekend) I will be validating > these patches and commiting them to that repo. > > Erik Sooo any news? ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
JonY wrote: > > Wow ok, haven't touched it since the gnone2 days, it was pretty decent > > back then. > > > > I'll come back later then. > > > > Ping, anything new? Well I've replaced Gnome3 with XMonad which is a huse step in the right direction. Still super busy with a bunch of other things (eg family, the day job and looking for a new day job :-) ). I do expect to get around to this. Just having a bit of trouble having a nice clean 6-8 hour block which I can devote to this. If anyone else has free time, I'd have no problem with them jumping in and helping. Just please co-ordinate here. 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
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/16/2011 06:49, JonY wrote: > On 11/16/2011 03:20, Erik de Castro Lopo wrote: >> JonY wrote: >> >>> On 11/14/2011 18:01, JonY wrote: On 11/10/2011 19:22, JonY wrote: > On 11/10/2011 18:39, Erik de Castro Lopo wrote: >> >> I'm subscribed to the list (and I set my reply-to to the list). >> Please do not CC me. >> >> JonY wrote: >> >>> Its probably on one of the sf tracker somewhere, I can't seem to find it >>> anymore. It wasn't anything complicated, so I should be able to redo it >>> quickly. >> >> I'm a Linux guy. I do not have easy access to a windows machine >> and don't have the time or patience to maintain one. >> >> For windows stuff I'll be relying on others to provide and test >> patches. >> >> Erik > > Alright, here's a quick fix, although it is more ugly than I remembered. > > Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h > where available, and falls back to I64 on MSVC and then ll for others, > all format warnings suppressed. > > Tested on MinGW. > > Sven-Hendrik, or any other mingw guys around, do you mind testing the > patch too? Patch based on git master from > https://git.xiph.org/mirrors/flac.git. > Ifdef changes now consolidated into a single file. >>> >>> Ping, no comments? >>> >>> I noticed some more ifdeferies around that needs consolidating and >>> warnings that need suppressing, that can go into a separate patch. >> >> Sorry, I got hit by the Gnome3 catastrophe of 2011 and I'm still trying >> to make my machine usable. >> >> Erik > > Wow ok, haven't touched it since the gnone2 days, it was pretty decent > back then. > > I'll come back later then. > Ping, anything new? signature.asc Description: OpenPGP digital signature ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On Wed, Nov 16, 2011 at 03:36:12PM -0800, bri...@sounds.wa.com wrote: > > This will leave Apple with even less reasons to support FLAC ... > > You make some important observations, but I do not see how anything > can be done by the FLAC team about Apple's lack of support. I think that only people who work for Apple can do anything to persuade Apple to (ahem) think different about FLAC. I'm guessing there is a strong "Not Invented Here" effect at work. > As for FLAC, no news is good news. That means the code is stable and > bug free. I appreciate that, a lot. That's why I run mostly Debian or Ubuntu LTS on machines that need to be stable (but don't need to have the latest fancy stuff). Unfortunately, most people tend to prefer the latest fancy stuff (in devices and installed software) so for those people lack of change is usually seen as a bad thing. Although having said that, last time I had to install FLAC on a Windows PC (someone else's) the GUI front-end that I downloaded came with an older flac.exe than the current FLAC version at the time. > It seems that all of the recent updates have been efforts to port > FLAC to operating systems like Windows and Linux. In terms of your > comments above, Windows/Linux support does absolutely nothing to help > FLAC compete against ALAC on the OSX platform. Not directly, no... ...but most people like New Stuff as opposed to not fixing something that isn't broken. Enough to cause more interest in Apple Lossless as a supported format (outside of Apple devices) and therefore less interest in FLAC. It could even cause some music download sites to reconsider their support of FLAC. > It is indeed noteworthy that Apple has released the source for ALAC. > The power of FLAC is that it was designed for embedded systems from > the beginning, and that's why you see portable recorders like the > Sound Devices 700 Series supporting FLAC, as well as various optical > disc players (CD, DVD, etc.). One question that remains for me is > whether Apple's ALAC open source can be ported to these kinds of > embedded systems with the same ease. I wish I could afford a portable recorder from Sound Devices! They record multichannel or stereo in FLAC aswell as playing it, right? Obviously, FLAC requires much less horsepower to decode than to encode, and that's OK (for most uses) because the decode will happen more often. I can live with uncompressed recording, but when buying hardware, FLAC support is always a deciding factor. However, almost every device that can play audio (from el-cheapo DVD players, to almost every "pro" DJ or broadcast deck) is able to play MP3 files. Most of them can also play WMA and AAC (lossy), but FLAC support on mass-market devices is rare. There is such a huge variety of chipsets and other hardware elements that it's impractical to port Rockbox to them. For example, OPPO do some very nice DVD and BD players for the home theatre and audiophile markets. But only their top-range players can play FLAC files. That is according to their own website, but it may be a "hidden extra". Similarly, CD DJ decks from Pioneer and Denon seem to support every lossy compressed audio format, but not lossless. And to make it even worse, Silvio Zeppieri (Denon brand manager) commented on www.denondjforums.com (in Feb 2010) that their reason for not supporting FLAC was that hard drives are cheap now, so just use WAV for "lossless" instead, as it would cost Denon too much to develop FLAC support. FolderPlay (app for Nokia S60) is what I listen to music with on the move every day (mostly FLAC, some MP3) and the developer told me that it took him half a day to add FLAC support. Whereas Denon were afraid that the DJ features (scratch, loop in/out points, etc) that are already possible on Denon hardware in WAV, will cost them too much development time to support in FLAC. What impressed me most about the discussion on www.denondjforums.com wasn't the overall defeatist attitude from a Denon manager (he said "no direct FLAC sales" in Feb 2010), but that most of the other people on the forum agreed that hard drives are so cheap that lossless has no real advantage: digital DJs should either use MP3s (not caring about sound quality) or WAV (not caring about storage space). And now we find ourselves in a world where hard drives are suddenly not cheap anymore... -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On Thu, Nov 10, 2011 at 09:58:03AM +1100, Erik de Castro Lopo wrote: > If anyone else has Flac patches that they would like to > see commited to the Xiph Git repo, now would be a good time > to speak up. 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 There are other patches which I think you might find useful: -asm, -gcc43 and -hidesyms. I can prepare proper git patches, if interested. Thanks, -- Miroslav Lichvar ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
Well the memory leak I mentioned in my previous message for one. But there are plenty more listed here: http://sourceforge.net/tracker/?atid=113478&group_id=13478&func=browse and here: http://sourceforge.net/tracker/?atid=313478&group_id=13478&func=browse Admittedly I haven't read all of those, maybe some are invalid or actually feature requests, but surely some more actual, valid bugs are listed there as well. So I would be happy if (after 2 years) someone would take care of a couple of open reports. At least those where users have already submitted patches to fix them (after reviewing the patch of course). --- On Sat, 11/19/11, Brian Willoughby wrote: > From: Brian Willoughby > Subject: Re: [Flac-dev] Git branch with compiling fixes for win32 > To: "Bastiaan Timmer" > Cc: flac-dev@xiph.org > Date: Saturday, November 19, 2011, 4:48 AM > What bugs? > > On Nov 18, 2011, at 04:16, Bastiaan Timmer wrote: > > It's good to see some updates to the FLAC project > after so much time! Will there be any timeline for a > bugfix-release? > > > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
What bugs? On Nov 18, 2011, at 04:16, Bastiaan Timmer wrote: > It's good to see some updates to the FLAC project after so much > time! Will there be any timeline for a bugfix-release? ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
Well, I have been away a couple of days, so I don't know if I'm in time, but I reported a memory leak and submitted a patch a couple of months ago. It would be nice if it can make it in. I first reported the leak here: http://lists.xiph.org/pipermail/flac-dev/2011-August/003002.html And the patch is here: http://sourceforge.net/tracker/?func=detail&aid=3390048&group_id=13478&atid=313478 And there are plenty more patches on the sourceforge tracker if you want to apply more. (But I obviously haven't checked them all and what they are supposed to fix.) It's good to see some updates to the FLAC project after so much time! Will there be any timeline for a bugfix-release? thanks, Bas Timmer --- On Wed, 11/9/11, Erik de Castro Lopo wrote: > From: Erik de Castro Lopo > Subject: Re: [Flac-dev] Git branch with compiling fixes for win32 > To: flac-dev@xiph.org > Date: Wednesday, November 9, 2011, 10:58 PM > Sven-Hendrik Haase wrote: > > > Si señor: http://code.entropywave.com/git/flac.git > > Ok, there are about 6 commits there. Over the weekend I'll > have a look at them and if they're fine, I'll push them to > the Xiph Git repo. > > If anyone else has Flac patches that they would like to > see commited to the Xiph Git repo, now would be a good > time > to speak up. > > 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] Git branch with compiling fixes for win32
On Nov 16, 2011, at 14:11, Declan Kelly wrote: > On Wed, Nov 16, 2011 at 05:41:21AM -0800, avu...@gmail.com wrote: >> Hate to be Capt. obvious here, but there's a lot of development going >> on here that should be encouraged. If the FLAC project isn't going to >> open up, it would make a lot of sense for someone to take over >> maintenance on a github account with the git-cvsimport or such. I >> don't see anyone stepping up, me included, but I wanted to throw this >> out there in case someone hasn't really thought about it yet. > > Looking at the FLAC website, the most recent news is almost 2 years > old, > and there's no evidence to show that the project's still live. I > haven't > seen any post from Josh Coalson on this list in a while: is he still > running the project? > > Something else to think about: > Apple recently released sources for Apple Lossless reference > utilities. > It's all under an Apache license. > > This will (presumably) lead to more software developers spending more > time improving ALAC support in their projects, with more reference > material available than the unofficial reverse-engineered code (as > used > in vlc and libavcodec). > > This will leave Apple with even less reasons to support FLAC in their > own products. Anyone with an iPad/iPhone/iPod must install Rockbox to > play FLAC files, and the Apple TV can only play FLAC (and anything > that > was not bought from iTunes) using XBMC, after being jailbroken. > > But for the Average End User, they don't want to have to jump > through a > bunch of hoops to get FLAC support. Apple Lossless will Just Work > on all > Apple devices (as it always did), but now it's more freely > available so > the freedom-loving hippies can stop complaining about the source code. Declan, You make some important observations, but I do not see how anything can be done by the FLAC team about Apple's lack of support. As for FLAC, no news is good news. That means the code is stable and bug free. As a seasoned software developer, I've learned the hard way that every single change to a source code repository is a chance for a new or old bug to appear. I am not aware of any bugs in FLAC, so the lack of changes is perfect. It seems that all of the recent updates have been efforts to port FLAC to operating systems like Windows and Linux. In terms of your comments above, Windows/Linux support does absolutely nothing to help FLAC compete against ALAC on the OSX platform. It is indeed noteworthy that Apple has released the source for ALAC. The power of FLAC is that it was designed for embedded systems from the beginning, and that's why you see portable recorders like the Sound Devices 700 Series supporting FLAC, as well as various optical disc players (CD, DVD, etc.). One question that remains for me is whether Apple's ALAC open source can be ported to these kinds of embedded systems with the same ease. Yes, it has always been an issue that Apple never seemed motivated to support FLAC as a first class file format in OSX, CoreAudio, iTunes, and their hardware platforms based on iOS. I really don't see how there is much that Josh Coalson or anyone outside Apple can do about this. If people in the FLAC community have CoreAudio converters for FLAC or iTunes plugins for FLAC, then it would be great to see those contributed to the open source collection. However, none of those items would really result in a change to the FLAC library sources, which have been stable and solid for a respectable amount of time. Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On Wed, Nov 16, 2011 at 05:41:21AM -0800, avu...@gmail.com wrote: > Hate to be Capt. obvious here, but there's a lot of development going > on here that should be encouraged. If the FLAC project isn't going to > open up, it would make a lot of sense for someone to take over > maintenance on a github account with the git-cvsimport or such. I > don't see anyone stepping up, me included, but I wanted to throw this > out there in case someone hasn't really thought about it yet. Looking at the FLAC website, the most recent news is almost 2 years old, and there's no evidence to show that the project's still live. I haven't seen any post from Josh Coalson on this list in a while: is he still running the project? Something else to think about: Apple recently released sources for Apple Lossless reference utilities. It's all under an Apache license. This will (presumably) lead to more software developers spending more time improving ALAC support in their projects, with more reference material available than the unofficial reverse-engineered code (as used in vlc and libavcodec). This will leave Apple with even less reasons to support FLAC in their own products. Anyone with an iPad/iPhone/iPod must install Rockbox to play FLAC files, and the Apple TV can only play FLAC (and anything that was not bought from iTunes) using XBMC, after being jailbroken. But for the Average End User, they don't want to have to jump through a bunch of hoops to get FLAC support. Apple Lossless will Just Work on all Apple devices (as it always did), but now it's more freely available so the freedom-loving hippies can stop complaining about the source code. -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
Avuton Olrich wrote: > Hello, > > Hate to be Capt. obvious here, but there's a lot of development going > on here that should be encouraged. If the FLAC project isn't going to > open up, it would make a lot of sense for someone to take over > maintenance on a github account with the git-cvsimport or such. I > don't see anyone stepping up, me included, but I wanted to throw this > out there in case someone hasn't really thought about it yet. There is a Git branch on the Xiph server here: http://git.xiph.org/?p=flac.git;a=summary When I find a little bit of time (the weekend) I will be validating these patches and commiting them to that repo. 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
Re: [Flac-dev] Git branch with compiling fixes for win32
Hello, Hate to be Capt. obvious here, but there's a lot of development going on here that should be encouraged. If the FLAC project isn't going to open up, it would make a lot of sense for someone to take over maintenance on a github account with the git-cvsimport or such. I don't see anyone stepping up, me included, but I wanted to throw this out there in case someone hasn't really thought about it yet. -- avuton -- If someone nearby has an iphone and leaves it near you, be aware they may be spying on you. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/09/11 02:58 pm, Erik de Castro Lopo wrote: If anyone else has Flac patches that they would like to see commited to the Xiph Git repo, now would be a good time to speak up. A couple of build system fixes for OS/2. Not very experienced with git so just attaching. Dave From e47dc34e2025cf0b700a8ff9ebbb7fac7e7999f1 Mon Sep 17 00:00:00 2001 From: Dave Yeo Date: Tue, 15 Nov 2011 20:37:16 -0800 Subject: [PATCH 1/2] GCC on OS/2 defaults to A.OUT so nasm should also generate A.OUT object files --- configure.in |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/configure.in b/configure.in index c6497a0..516edea 100644 --- a/configure.in +++ b/configure.in @@ -93,6 +93,7 @@ case "$host" in i386-*-openbsd3.[[0-3]]) OBJ_FORMAT=aoutb ;; *-*-cygwin|*mingw*) OBJ_FORMAT=win32 ;; *-*-darwin*) OBJ_FORMAT=macho ;; + *os2*) OBJ_FORMAT=aout ;; *) OBJ_FORMAT=elf ;; esac AC_SUBST(OBJ_FORMAT) -- 1.7.2.3 From 99a10229202ece9fd0be41af387911c694038187 Mon Sep 17 00:00:00 2001 From: Dave Yeo Date: Tue, 15 Nov 2011 21:25:47 -0800 Subject: [PATCH 2/2] Libtool fix for OS/2 to create shared libs (DLL) Libtool dies with this error "libtool: link: warning: undefined symbols not allowed in i386-pc-os2-emx shared libraries" without being passed --no-undefined --- configure.in |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/configure.in b/configure.in index 516edea..efed8dc 100644 --- a/configure.in +++ b/configure.in @@ -100,11 +100,15 @@ AC_SUBST(OBJ_FORMAT) case "$host" in *-*-cygwin|*mingw*) - # define this variable for enabling strict exports with libtool; for now, it's only supported by Win32 + # define this variable for enabling strict exports with libtool LT_NO_UNDEFINED="-no-undefined" # -lwsock32 only needed because of ntohl() usage, can get rid of after that's gone: MINGW_WINSOCK_LIBS=-lwsock32 ;; + *os2*) + # OS/2 also supports this variable and needs it to produce a DLL + LT_NO_UNDEFINED="-no-undefined" + ;; *) LT_NO_UNDEFINED= MINGW_WINSOCK_LIBS= -- 1.7.2.3 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/16/2011 03:20, Erik de Castro Lopo wrote: > JonY wrote: > >> On 11/14/2011 18:01, JonY wrote: >>> On 11/10/2011 19:22, JonY wrote: On 11/10/2011 18:39, Erik de Castro Lopo wrote: > > I'm subscribed to the list (and I set my reply-to to the list). > Please do not CC me. > > JonY wrote: > >> Its probably on one of the sf tracker somewhere, I can't seem to find it >> anymore. It wasn't anything complicated, so I should be able to redo it >> quickly. > > I'm a Linux guy. I do not have easy access to a windows machine > and don't have the time or patience to maintain one. > > For windows stuff I'll be relying on others to provide and test > patches. > > Erik Alright, here's a quick fix, although it is more ugly than I remembered. Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h where available, and falls back to I64 on MSVC and then ll for others, all format warnings suppressed. Tested on MinGW. Sven-Hendrik, or any other mingw guys around, do you mind testing the patch too? Patch based on git master from https://git.xiph.org/mirrors/flac.git. >>> >>> Ifdef changes now consolidated into a single file. >> >> Ping, no comments? >> >> I noticed some more ifdeferies around that needs consolidating and >> warnings that need suppressing, that can go into a separate patch. > > Sorry, I got hit by the Gnome3 catastrophe of 2011 and I'm still trying > to make my machine usable. > > Erik Wow ok, haven't touched it since the gnone2 days, it was pretty decent back then. I'll come back later then. signature.asc Description: OpenPGP digital signature ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
JonY wrote: > On 11/14/2011 18:01, JonY wrote: > > On 11/10/2011 19:22, JonY wrote: > >> On 11/10/2011 18:39, Erik de Castro Lopo wrote: > >>> > >>> I'm subscribed to the list (and I set my reply-to to the list). > >>> Please do not CC me. > >>> > >>> JonY wrote: > >>> > Its probably on one of the sf tracker somewhere, I can't seem to find it > anymore. It wasn't anything complicated, so I should be able to redo it > quickly. > >>> > >>> I'm a Linux guy. I do not have easy access to a windows machine > >>> and don't have the time or patience to maintain one. > >>> > >>> For windows stuff I'll be relying on others to provide and test > >>> patches. > >>> > >>> Erik > >> > >> Alright, here's a quick fix, although it is more ugly than I remembered. > >> > >> Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h > >> where available, and falls back to I64 on MSVC and then ll for others, > >> all format warnings suppressed. > >> > >> Tested on MinGW. > >> > >> Sven-Hendrik, or any other mingw guys around, do you mind testing the > >> patch too? Patch based on git master from > >> https://git.xiph.org/mirrors/flac.git. > >> > > > > Ifdef changes now consolidated into a single file. > > Ping, no comments? > > I noticed some more ifdeferies around that needs consolidating and > warnings that need suppressing, that can go into a separate patch. Sorry, I got hit by the Gnome3 catastrophe of 2011 and I'm still trying to make my machine usable. 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
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/14/2011 18:01, JonY wrote: > On 11/10/2011 19:22, JonY wrote: >> On 11/10/2011 18:39, Erik de Castro Lopo wrote: >>> >>> I'm subscribed to the list (and I set my reply-to to the list). >>> Please do not CC me. >>> >>> JonY wrote: >>> Its probably on one of the sf tracker somewhere, I can't seem to find it anymore. It wasn't anything complicated, so I should be able to redo it quickly. >>> >>> I'm a Linux guy. I do not have easy access to a windows machine >>> and don't have the time or patience to maintain one. >>> >>> For windows stuff I'll be relying on others to provide and test >>> patches. >>> >>> Erik >> >> Alright, here's a quick fix, although it is more ugly than I remembered. >> >> Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h >> where available, and falls back to I64 on MSVC and then ll for others, >> all format warnings suppressed. >> >> Tested on MinGW. >> >> Sven-Hendrik, or any other mingw guys around, do you mind testing the >> patch too? Patch based on git master from >> https://git.xiph.org/mirrors/flac.git. >> > > Ifdef changes now consolidated into a single file. Ping, no comments? I noticed some more ifdeferies around that needs consolidating and warnings that need suppressing, that can go into a separate patch. signature.asc Description: OpenPGP digital signature ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/10/2011 19:22, JonY wrote:
> On 11/10/2011 18:39, Erik de Castro Lopo wrote:
>>
>> I'm subscribed to the list (and I set my reply-to to the list).
>> Please do not CC me.
>>
>> JonY wrote:
>>
>>> Its probably on one of the sf tracker somewhere, I can't seem to find it
>>> anymore. It wasn't anything complicated, so I should be able to redo it
>>> quickly.
>>
>> I'm a Linux guy. I do not have easy access to a windows machine
>> and don't have the time or patience to maintain one.
>>
>> For windows stuff I'll be relying on others to provide and test
>> patches.
>>
>> Erik
>
> Alright, here's a quick fix, although it is more ugly than I remembered.
>
> Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h
> where available, and falls back to I64 on MSVC and then ll for others,
> all format warnings suppressed.
>
> Tested on MinGW.
>
> Sven-Hendrik, or any other mingw guys around, do you mind testing the
> patch too? Patch based on git master from
> https://git.xiph.org/mirrors/flac.git.
>
Ifdef changes now consolidated into a single file.
diff --git a/include/FLAC/compat.h b/include/FLAC/compat.h
new file mode 100755
index 000..83ccc9e
--- /dev/null
+++ b/include/FLAC/compat.h
@@ -0,0 +1,53 @@
+/* libFLAC - Free Lossless Audio Codec library
+ * Copyright (C) 2001,2002,2003,2004,2005,2006,2007,2008,2009 Josh Coalson
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * - Neither the name of the Xiph.org Foundation nor the names of its
+ * contributors may be used to endorse or promote products derived from
+ * this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef FLAC__COMPAT_H
+#define FLAC__COMPAT_H
+
+#if HAVE_CONFIG_H
+# include
+#endif
+
+#ifdef HAVE_INTTYPES_H
+#include
+#define flactypei64 PRId64
+#define flactypeu64 PRIu64
+#else
+#ifdef _MSC_VER
+#define flactypei64 "I64d"
+#define flactypeu64 "I64u"
+#else
+#define flactypei64 "lld"
+#define flactypeu64 "llu"
+#endif
+#endif
+
+#endif
diff --git a/src/flac/analyze.c b/src/flac/analyze.c
index 1073758..6865f3b 100644
--- a/src/flac/analyze.c
+++ b/src/flac/analyze.c
@@ -26,6 +26,7 @@
#include
#include
#include "FLAC/all.h"
+#include "FLAC/compat.h"
#include "analyze.h"
typedef struct {
@@ -66,11 +67,7 @@ void flac__analyze_frame(const FLAC__Frame *frame, unsigned
frame_number, FLAC__
unsigned i, channel, partitions;
/* do the human-readable part first */
-#ifdef _MSC_VER
- fprintf(fout,
"frame=%u\toffset=%I64u\tbits=%u\tblocksize=%u\tsample_rate=%u\tchannels=%u\tchannel_assignment=%s\n",
frame_number, frame_offset, frame_bytes*8, frame->header.blocksize,
frame->header.sample_rate, channels,
FLAC__ChannelAssignmentString[frame->header.channel_assignment]);
-#else
- fprintf(fout,
"frame=%u\toffset=%llu\tbits=%u\tblocksize=%u\tsample_rate=%u\tchannels=%u\tchannel_assignment=%s\n",
frame_number, (unsigned long long)frame_offset, frame_bytes*8,
frame->header.blocksize, frame->header.sample_rate, channels,
FLAC__ChannelAssignmentString[frame->header.channel_assignment]);
-#endif
+ fprintf(fout,
"frame=%u\toffset=%"flactypei64"\tbits=%u\tblocksize=%u\tsample_rate=%u\tchannels=%u\tchannel_assignment=%s\n",
frame_number, (unsigned long long)frame_offset, frame_bytes*8,
frame->header.blocksize, frame->header.sample_rate, channels,
FLAC__ChannelAssignmentString[frame->header.channel_assignment]);
for(channel = 0; channel < channels; channel++) {
const FLAC__Subframe *subframe = frame->subframes+channel;
const FLAC__bool is_rice2 =
subframe->data.fixed.entropy_coding_method.type ==
FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE2;
diff --git a/src/metaflac/operati
Re: [Flac-dev] Git branch with compiling fixes for win32
> > Development is probably complete. Maintenance should continue. Speaking of which, I plan on starting AMD64, ARMv5, and ARMv7 assembly routines in the next few weeks. I'll sync up with Erik on getting them integrated. -Ben Allison ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/10/2011 18:39, Erik de Castro Lopo wrote:
>
> I'm subscribed to the list (and I set my reply-to to the list).
> Please do not CC me.
>
> JonY wrote:
>
>> Its probably on one of the sf tracker somewhere, I can't seem to find it
>> anymore. It wasn't anything complicated, so I should be able to redo it
>> quickly.
>
> I'm a Linux guy. I do not have easy access to a windows machine
> and don't have the time or patience to maintain one.
>
> For windows stuff I'll be relying on others to provide and test
> patches.
>
> Erik
Alright, here's a quick fix, although it is more ugly than I remembered.
Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h
where available, and falls back to I64 on MSVC and then ll for others,
all format warnings suppressed.
Tested on MinGW.
Sven-Hendrik, or any other mingw guys around, do you mind testing the
patch too? Patch based on git master from
https://git.xiph.org/mirrors/flac.git.
diff --git a/src/flac/analyze.c b/src/flac/analyze.c
index 1073758..d4a4441 100644
--- a/src/flac/analyze.c
+++ b/src/flac/analyze.c
@@ -28,6 +28,20 @@
#include "FLAC/all.h"
#include "analyze.h"
+#ifdef HAVE_INTTYPES_H
+#include
+#define flactypei64 PRId64
+#define flactypeu64 PRIu64
+#else
+#ifdef _MSC_VER
+#define flactypei64 "I64d"
+#define flactypeu64 "I64u"
+#else
+#define flactypei64 "lld"
+#define flactypeu64 "llu"
+#endif
+#endif
+
typedef struct {
FLAC__int32 residual;
unsigned count;
@@ -66,11 +80,7 @@ void flac__analyze_frame(const FLAC__Frame *frame, unsigned
frame_number, FLAC__
unsigned i, channel, partitions;
/* do the human-readable part first */
-#ifdef _MSC_VER
- fprintf(fout,
"frame=%u\toffset=%I64u\tbits=%u\tblocksize=%u\tsample_rate=%u\tchannels=%u\tchannel_assignment=%s\n",
frame_number, frame_offset, frame_bytes*8, frame->header.blocksize,
frame->header.sample_rate, channels,
FLAC__ChannelAssignmentString[frame->header.channel_assignment]);
-#else
- fprintf(fout,
"frame=%u\toffset=%llu\tbits=%u\tblocksize=%u\tsample_rate=%u\tchannels=%u\tchannel_assignment=%s\n",
frame_number, (unsigned long long)frame_offset, frame_bytes*8,
frame->header.blocksize, frame->header.sample_rate, channels,
FLAC__ChannelAssignmentString[frame->header.channel_assignment]);
-#endif
+ fprintf(fout,
"frame=%u\toffset=%"flactypei64"\tbits=%u\tblocksize=%u\tsample_rate=%u\tchannels=%u\tchannel_assignment=%s\n",
frame_number, (unsigned long long)frame_offset, frame_bytes*8,
frame->header.blocksize, frame->header.sample_rate, channels,
FLAC__ChannelAssignmentString[frame->header.channel_assignment]);
for(channel = 0; channel < channels; channel++) {
const FLAC__Subframe *subframe = frame->subframes+channel;
const FLAC__bool is_rice2 =
subframe->data.fixed.entropy_coding_method.type ==
FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE2;
diff --git a/src/metaflac/operations.c b/src/metaflac/operations.c
index 639a1da..e43e073 100644
--- a/src/metaflac/operations.c
+++ b/src/metaflac/operations.c
@@ -32,6 +32,20 @@
#include
#include "operations_shorthand.h"
+#ifdef HAVE_INTTYPES_H
+#include
+#define flactypei64 PRId64
+#define flactypeu64 PRIu64
+#else
+#ifdef _MSC_VER
+#define flactypei64 "I64d"
+#define flactypeu64 "I64u"
+#else
+#define flactypei64 "lld"
+#define flactypeu64 "llu"
+#endif
+#endif
+
static void show_version(void);
static FLAC__bool do_major_operation(const CommandLineOptions *options);
static FLAC__bool do_major_operation_on_file(const char *filename, const
CommandLineOptions *options);
@@ -565,11 +579,7 @@ void write_metadata(const char *filename,
FLAC__StreamMetadata *block, unsigned
PPR; printf(" sample_rate: %u Hz\n",
block->data.stream_info.sample_rate);
PPR; printf(" channels: %u\n",
block->data.stream_info.channels);
PPR; printf(" bits-per-sample: %u\n",
block->data.stream_info.bits_per_sample);
-#ifdef _MSC_VER
- PPR; printf(" total samples: %I64u\n",
block->data.stream_info.total_samples);
-#else
- PPR; printf(" total samples: %llu\n", (unsigned long
long)block->data.stream_info.total_samples);
-#endif
+ PPR; printf(" total samples: %"flactypeu64"\n",
(unsigned long long)block->data.stream_info.total_samples);
PPR; printf(" MD5 signature: ");
for(i = 0; i < 16; i++) {
printf("%02x",
(unsigned)block->data.stream_info.md5sum[i]);
@@ -596,11 +606,7 @@ void write_metadata(const char *filename,
FLAC__StreamMetadata *block, unsigned
PPR; printf(" seek points: %u\n",
block->data.seek_table.num_points);
for(i = 0; i < block->data.seek_table.num_points; i++) {
if(block->data.seek_table.points[i].sample_number !=
FLAC__STREAM_METADAT
Re: [Flac-dev] Git branch with compiling fixes for win32
I'm subscribed to the list (and I set my reply-to to the list). Please do not CC me. JonY wrote: > Its probably on one of the sf tracker somewhere, I can't seem to find it > anymore. It wasn't anything complicated, so I should be able to redo it > quickly. I'm a Linux guy. I do not have easy access to a windows machine and don't have the time or patience to maintain one. For windows stuff I'll be relying on others to provide and test patches. 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
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/10/2011 18:13, Sean M. Pappalardo - D.J. Pegasus wrote: > Not sure if the patches you already have address this, but here are some > hacks I collected to try to get libFLAC to build on Windows for Mixxx: > http://mixxx.org/wiki/doku.php/build_windows_dependencies#libflac > > I have never actually gotten it to build on x64 and right now just use > OpenCodecs' distribution (also mentioned at that link) which has Visual > Studio files that build fine for me. > > Sincerely, > Sean M. Pappalardo > "D.J. Pegasus" > Mixxx Developer - Controller Specialist I have not built flac for win64, at least I don't remember I did. I'll investigate after I put up the printf patches. signature.asc Description: OpenPGP digital signature ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
Not sure if the patches you already have address this, but here are some hacks I collected to try to get libFLAC to build on Windows for Mixxx: http://mixxx.org/wiki/doku.php/build_windows_dependencies#libflac I have never actually gotten it to build on x64 and right now just use OpenCodecs' distribution (also mentioned at that link) which has Visual Studio files that build fine for me. Sincerely, Sean M. Pappalardo "D.J. Pegasus" Mixxx Developer - Controller Specialist ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/10/2011 08:02, Erik de Castro Lopo wrote: > JonY wrote: > >> I submitted a patch sometime ago to correct printf specifiers for win32 >> by using inttypes.h, but there were no response, so I thought flac >> development was dead. > > Development is probably complete. Maintenance should continue. > >> Not sure where the patch went or if its still valid. > > If you sent it to this list, the mailing list archive should be here: > > http://lists.xiph.org/mailman/listinfo/flac-dev > Its probably on one of the sf tracker somewhere, I can't seem to find it anymore. It wasn't anything complicated, so I should be able to redo it quickly. signature.asc Description: OpenPGP digital signature ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
JonY wrote: > I submitted a patch sometime ago to correct printf specifiers for win32 > by using inttypes.h, but there were no response, so I thought flac > development was dead. Development is probably complete. Maintenance should continue. > Not sure where the patch went or if its still valid. If you sent it to this list, the mailing list archive should be here: http://lists.xiph.org/mailman/listinfo/flac-dev 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
Re: [Flac-dev] Git branch with compiling fixes for win32
On 11/10/2011 06:58, Erik de Castro Lopo wrote: > Sven-Hendrik Haase wrote: > >> Si señor: http://code.entropywave.com/git/flac.git > > Ok, there are about 6 commits there. Over the weekend I'll > have a look at them and if they're fine, I'll push them to > the Xiph Git repo. > > If anyone else has Flac patches that they would like to > see commited to the Xiph Git repo, now would be a good time > to speak up. > > Cheers, > Erik I submitted a patch sometime ago to correct printf specifiers for win32 by using inttypes.h, but there were no response, so I thought flac development was dead. Not sure where the patch went or if its still valid. signature.asc Description: OpenPGP digital signature ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
Sven-Hendrik Haase wrote: > Si señor: http://code.entropywave.com/git/flac.git Ok, there are about 6 commits there. Over the weekend I'll have a look at them and if they're fine, I'll push them to the Xiph Git repo. If anyone else has Flac patches that they would like to see commited to the Xiph Git repo, now would be a good time to speak up. 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
Re: [Flac-dev] Git branch with compiling fixes for win32
Erik de Castro Lopo wrote: >Sven-Hendrik Haase wrote: > >> I found this git repo that contains fixes for mingw32 compilation of >> flac: git://code.entropywave.com/git/flac.git >> Switch to the "ew" branch to see the fixes. I'd be glad if this went >> upstream as it'd make my job easier. > >Is there a gitweb interface to this? > >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 Si señor: http://code.entropywave.com/git/flac.git -- Sven-Hendrik ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
Sven-Hendrik Haase wrote: > I found this git repo that contains fixes for mingw32 compilation of > flac: git://code.entropywave.com/git/flac.git > Switch to the "ew" branch to see the fixes. I'd be glad if this went > upstream as it'd make my job easier. Is there a gitweb interface to this? 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
