Re: [flac-dev] Status of flac; new release?
Hi again, On 29.11.2012, at 21:10, Erik de Castro Lopo wrote: Max Horn wrote: 1) Is there any chance the website could be updated? I'd like to have the flac.sf.net website re-directed to https://www.xiph.org/flac/ . Until the re-direct happens the rest of the world still points to sf.net. So we are still waiting for Josh to grant admin rights for the SF.net project to Ralph Giles (SF.net username 'giles') and or Erik (username?), which only requires a few clicks. If Josh does not reply within some more time, you could also simply request the SF.net staff to do this for you, by filing a support request at https://sourceforge.net/p/forge/site-support/new/ Of course they will want to ensure that you have a good case in taking over that SF.net project, esp. since flac is quite high profile. But I am sure that you can convince them, esp. by pointing to the xiph hosted git repos, and perhaps pointing to flac-dev archives which document that Erik is new maintainer, and that Josh knows about this: http://lists.xiph.org/pipermail/flac-dev/2012-February/003083.html http://lists.xiph.org/pipermail/flac-dev/2012-April/003345.html http://lists.xiph.org/pipermail/flac-dev/2012-April/003340.html (the last Back from hiatus -- sadly, it seems to have been a rather short return? :-( ) However, that all does not address my main wish: The new website still has exactly (?) the same content as the old one. Could you please at least add a single paragraph (ideally in big red bliniking letters?) that there is new development work in progress, with a link to the new git repos? This would be IMHO a very important and major improvement over the current state of total non-information... If you point me to the sources of the site (is there a repos for it?), I'll be happy to provide a patch for this, too! 2) Any chance for a new release? Just bug fixes would be enough. I'd like to do a release some time between now and xmas. That release would be something like what us in Xiph's git right now. 3) Does anybody feel responsible for going through the bug and patch trackers at SF.net? I did spend some time going through those. There didn't seem to be much there in terms of valuable patches. If there is something I can do to assist with any of these things, I'll try to help. The most useful thing would be to have a second look at the SF bug tracker and see it there is anything there that isn't already fixed in Xiph's git repo. OK. In order to avoid duplicating efforts, it would be good if everybody who reviews a patch leaves comments there, even if those simply indicate that the patch is obsolete. Until the website gets updated, I think it would also be helpful (for the patch submitter) to include a link to the new git repository. Of course closing those patches (which would be the nice thing to do) would require to have the appropriate rights first, but this can still be done later, as long as the review results are recorded on each item :-). As a start, I verified that my own ancient patch is obsolete now, and closed it myself. Cheers, Max ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Status of flac; new release?
On 12-12-12 10:47 AM, Max Horn wrote: If you point me to the sources of the site (is there a repos for it?), I'll be happy to provide a patch for this, too! The new site repo is https://git.xiph.org/flac-website.git As a start, I verified that my own ancient patch is obsolete now, and closed it myself. Thanks! -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Flac and SourceForge
Hi, I'm Rich Bowen, the Community Manager at SourceForge. I was just chatting with Fingolfin on IRC about the state of the Flac project, and I wanted to let you know that I've jumped into the fray. As Community Manager, I'm interested in the health of projects, and I spend a lot of time looking at projects like Flac that still get huge numbers of downloads, but haven't cut a release in a long time. Anyways, I understand that you guys have picked development back up, but just don't have admin access to the SF project. This is where I come in. I've sent email to the project admin of the project, to see if he's still reachable. I understand that you folks have already done that, so this is more a courtesy than anything else. If he objects, then we can't do much more, by policy. However, if he doesn't object, or if he doesn't respond at all, I'm inclined to give you guys the access that you need to do whatever it is that you want to do with this project - whatever that is. So, please let me know, either her on the list, or off-list, if you prefer, what the consensus is that you want to do. Specifically, who would be added to the SF project (I'd need SF user IDs). Ideally, with my official SourceForge hat on, I'd like for you to stay at SourceForge. But as an Open Source fanatic, I'm primarily interested in the health of this very important project, and whatever I can do to facilitate that. --Rich (rbo...@sourceforge.net) -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org Shosholoza ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Status of flac; new release?
On 12.12.2012, at 20:10, Ralph Giles wrote: On 12-12-12 10:47 AM, Max Horn wrote: If you point me to the sources of the site (is there a repos for it?), I'll be happy to provide a patch for this, too! The new site repo is https://git.xiph.org/flac-website.git Thanks. I'll restrict to small patches for now, as I would hope that real site was actually generating some of the content (e.g. the stuff on index.html, news.html and in the atom feed looks as if it is coming from a common source). Though I am inclined to remove the (severely outdated) russian version... Ah well, but let's start small :) Other than that, are there any other plans to overhaul the website already? As a start, I verified that my own ancient patch is obsolete now, and closed it myself. Thanks! I also got Rich Bowen (DrBacchus on IRC) to chime in on the whole SF.net project matter, but he email himself by now, so I'll let you guys figure it out from here ;). Cheers, Max ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] [PATCH 0/5] update build system
This patch series modernizes various aspects of the autotools based build system. There is a lot more that could and should be done, but I tried to stay conservative for now and just resolve some of the most obvious issues. Max Horn (5): configure: replace XIPH_C_FIND_ENDIAN by AC_C_BIGENDIAN autogen.sh: replace this by a simple call to autoreconf configure: always print ac_cv_c_compiler_gnu configure: merge AC_CHECK_HEADERS calls configure: modernize autoconf usage Makefile.am| 2 - autogen.sh | 168 +-- configure.ac | 36 +++--- doc/Makefile.am| 2 - doc/html/Makefile.am | 2 - doc/html/images/Makefile.am| 2 - doc/html/images/hw/Makefile.am | 2 - doc/html/ru/Makefile.am| 2 - include/share/Makefile.am | 2 - include/share/grabbag/Makefile.am | 2 - include/test_libs_common/Makefile.am | 2 - m4/endian.m4 | 177 - src/libFLAC/Makefile.am| 3 + src/plugin_common/Makefile.am | 2 - src/share/getopt/Makefile.am | 2 - src/share/grabbag/Makefile.am | 2 - src/share/replaygain_analysis/Makefile.am | 2 - src/share/replaygain_synthesis/Makefile.am | 2 - src/share/utf8/Makefile.am | 2 - 19 files changed, 25 insertions(+), 389 deletions(-) delete mode 100644 m4/endian.m4 -- 1.8.0.1.525.gaaf5ad5 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] [PATCH 1/5] configure: replace XIPH_C_FIND_ENDIAN by AC_C_BIGENDIAN
Signed-off-by: Max Horn m...@quendi.de
---
configure.ac | 10 +++-
m4/endian.m4 | 177 ---
2 files changed, 9 insertions(+), 178 deletions(-)
delete mode 100644 m4/endian.m4
diff --git a/configure.ac b/configure.ac
index 3899d68..f206b32 100644
--- a/configure.ac
+++ b/configure.ac
@@ -70,7 +70,15 @@ AC_CHECK_HEADERS([sys/param.h])
XIPH_C_BSWAP32
-XIPH_C_FIND_ENDIAN
+ac_cv_c_big_endian=0
+ac_cv_c_little_endian=0
+AC_C_BIGENDIAN([ac_cv_c_big_endian=1], [ac_cv_c_little_endian=1], [
+
AC_MSG_WARN([[*]])
+ AC_MSG_WARN([[*** Not able to determine endian-ness of target
processor. ]])
+ AC_MSG_WARN([[*** The constants CPU_IS_BIG_ENDIAN and
CPU_IS_LITTLE_ENDIAN in ]])
+ AC_MSG_WARN([[*** config.h may need to be hand editied.
]])
+
AC_MSG_WARN([[*]])
+])
AC_DEFINE_UNQUOTED(CPU_IS_BIG_ENDIAN, ${ac_cv_c_big_endian},
[Target processor is big endian.])
AC_DEFINE_UNQUOTED(CPU_IS_LITTLE_ENDIAN, ${ac_cv_c_little_endian},
diff --git a/m4/endian.m4 b/m4/endian.m4
deleted file mode 100644
index 87c1f49..000
--- a/m4/endian.m4
+++ /dev/null
@@ -1,177 +0,0 @@
-dnl Copyright (C) 2012 Xiph.org Foundation
-dnl
-dnl Redistribution and use in source and binary forms, with or without
-dnl modification, are permitted provided that the following conditions
-dnl are met:
-dnl
-dnl - Redistributions of source code must retain the above copyright
-dnl notice, this list of conditions and the following disclaimer.
-dnl
-dnl - Redistributions in binary form must reproduce the above copyright
-dnl notice, this list of conditions and the following disclaimer in the
-dnl documentation and/or other materials provided with the distribution.
-dnl
-dnl - Neither the name of the Xiph.org Foundation nor the names of its
-dnl contributors may be used to endorse or promote products derived from
-dnl this software without specific prior written permission.
-dnl
-dnl THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-dnl ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-dnl LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-dnl A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR
-dnl CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
-dnl EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
-dnl PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
-dnl PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
-dnl LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
-dnl NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
-dnl SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-
-dnl @synopsis XIPH_C_FIND_ENDIAN
-dnl
-dnl Determine endian-ness of target processor.
-dnl @version 1.1 Mar 03 2002
-dnl @author Erik de Castro Lopo er...@mega-nerd.com
-dnl
-dnl Majority written from scratch to replace the standard autoconf macro
-dnl AC_C_BIGENDIAN. Only part remaining from the original is the invocation
-dnl of the AC_TRY_RUN macro.
-dnl
-dnl Find endian-ness in the following way:
-dnl1) Look in endian.h.
-dnl2) If 1) fails, look in sys/types.h and sys/param.h.
-dnl3) If 1) and 2) fails and not cross compiling run a test program.
-dnl4) If 1) and 2) fails and cross compiling then guess based on target.
-
-AC_DEFUN([XIPH_C_FIND_ENDIAN],
-[AC_CACHE_CHECK(processor byte ordering,
- ac_cv_c_byte_order,
-
-# Initialize to unknown
-ac_cv_c_byte_order=unknown
-
-if test x$ac_cv_header_endian_h = xyes ; then
-
- # First try endian.h which should set BYTE_ORDER.
-
- [AC_TRY_LINK([
- #include endian.h
- #if BYTE_ORDER != LITTLE_ENDIAN
- not big endian
- #endif
- ], return 0 ;,
- ac_cv_c_byte_order=little
- )]
-
- [AC_TRY_LINK([
- #include endian.h
- #if BYTE_ORDER != BIG_ENDIAN
- not big endian
- #endif
- ], return 0 ;,
- ac_cv_c_byte_order=big
- )]
-
- fi
-
-if test $ac_cv_c_byte_order = unknown ; then
-
- [AC_TRY_LINK([
- #include sys/types.h
- #include sys/param.h
- #if !BYTE_ORDER || !BIG_ENDIAN || !LITTLE_ENDIAN
- bogus endian macros
- #endif
- ], return 0 ;,
-
- [AC_TRY_LINK([
- #include sys/types.h
- #include sys/param.h
- #if BYTE_ORDER != LITTLE_ENDIAN
- not big endian
- #endif
Re: [flac-dev] [PATCH 2/5] autogen.sh: replace this by a simple call to autoreconf
Small remark: diff --git a/src/libFLAC/Makefile.am b/src/libFLAC/Makefile.am index 13ab593..aa88100 100644 --- a/src/libFLAC/Makefile.am +++ b/src/libFLAC/Makefile.am @@ -34,6 +34,9 @@ noinst_LTLIBRARIES = libFLAC-static.la if DEBUG DEBUGCFLAGS = -DFLAC__OVERFLOW_DETECT endif + +# FIXME: The following logic should be part of configure, not of Makefile.am + if FLaC__CPU_PPC # The -force_cpusubtype_ALL is needed to insert a ppc64 instruction # into cpu.c with an asm(). I committed this FIXME comment by mistake, although I stand by its content ;). Anyway, it logically does not really belong into this commit, so you may want to prune it before applying. Alternatively, I can also re-roll the patch series (and if I have to re-roll it anyway for other reasons, I'll remove it, too). Cheers, Max ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Flac and SourceForge
Rich Bowen wrote: Hi, I'm Rich Bowen, the Community Manager at SourceForge. Thanks Rich. Replied directly to you CCing Ralph Giles who has an SF.net account. 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] Flac and SourceForge
On Dec 12, 2012, at 4:07 PM, Ralph Giles wrote: On 12-12-12 11:18 AM, Rich Bowen wrote: So, please let me know, either her on the list, or off-list, if you prefer, what the consensus is that you want to do. Specifically, who would be added to the SF project (I'd need SF user IDs). Thanks for taking an interest. If Josh doesn't object, you can add me as an admin to the SF.net project and I can take care of updating the website. My SourceForge id is 'giles'. The main problem here is that Josh isn't responding. If anyone is in touch with him and can get an explicit OK from him, that would greatly simplify the process on my end. -- Rich Bowen rbo...@rcbowen.com Shosholoza ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH 2/5] autogen.sh: replace this by a simple call to autoreconf
Max Horn wrote: + +# FIXME: The following logic should be part of configure, not of Makefile.am + if FLaC__CPU_PPC # The -force_cpusubtype_ALL is needed to insert a ppc64 instruction # into cpu.c with an asm(). I committed this FIXME comment by mistake, although I stand by its content ;). Anyway, it logically does not really belong into this commit, so you may want to prune it before applying. Alternatively, I can also re-roll the patch series (and if I have to re-roll it anyway for other reasons, I'll remove it, too). I'm going to leave it in and remove it when I fix that issue. I have a PPC machine which also has a PPC64 chroot. 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] Flac and SourceForge
Hi Josh, I know you're busy, but could you please respond, one way or the other, whether I should have access to the flac.sf.net site to point it at the recent maintainership work Erik has been coordinating at Xiph.Org? Thanks, -r On 12-12-12 1:18 PM, Rich Bowen wrote: So, please let me know, either her on the list, or off-list, if you prefer, what the consensus is that you want to do. Specifically, who would be added to the SF project (I'd need SF user IDs). Thanks for taking an interest. If Josh doesn't object, you can add me as an admin to the SF.net http://SF.net project and I can take care of updating the website. My SourceForge id is 'giles'. The main problem here is that Josh isn't responding. If anyone is in touch with him and can get an explicit OK from him, that would greatly simplify the process on my end. -- Rich Bowen rbo...@rcbowen.com mailto:rbo...@rcbowen.com Shosholoza ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Status of flac; new release?
Martijn van Beurden wrote: Okay, this is weird. I just tried to send it again, but it doesn't appear in the archives, so I suppose it didn't make it? I don't get a warning or error mail however. It probably has to do with the size of the patch (as I changed the feed from an atom to RSS format) which is 80kb I've uploaded it to http://www.icer.nl/misc_stuff/flac-website-feed-update.diff It's the first time I tried to do something useful with git, so I'm not sure whether this is the right format, please let me know if it is incorrect. Looks good from a patch point of view (as it in applied without a hitch). Thanks for your work on this. Really good stuff. 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] Status of flac; new release?
Erik de Castro Lopo wrote: Thanks for your work on this. Really good stuff. Up on the xiph.org site now: https://www.xiph.org/flac/ Btw Martijn if you'd like your name in the actual commit in git, look at the git format-patch command. 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] Questions about FLAC documentation
If you only have a C compiler then you were doomed to start with. :P On Sat, Oct 6, 2012 at 5:04 AM, Ivailo Karamanolev ivail...@gmail.com wrote: If you only have a C compiler, how can you compile the C++ code to put a C frontend on it? On Sat, Oct 6, 2012 at 2:01 AM, Gravis f...@adaptivetime.com wrote: I'm implementing a FLAC decoder from scratch (save OGG stuff if I can help it) because libFLAC simply will not fit my embedded platform, For the most part I'm implementing using just the documentation but not all of the documentation is concise (especially about variable sized fields) and after looking at the libFLAC source I find myself befuddled so I thought it best to get the information from the people who know these things. So... In FRAME_HEADER there is a field of a variable size field with the description if(variable blocksize) \n 8-56 : 'UTF-8' coded sample number (decoded number is 36 bits) and I find the encoding scheme is somehow alien (I can't figure out what it has to do with UTF-8) and it's two following fields to be incomprehensible. There doesn't seem to be any information indicating their purpose either. The location and coding of audio samples is very nebulous in that I don't know where they are or the specifics of how any of their encoding scheme work. More details, links to more information and maybe even some pseudo code would be very helpful. The documentation about the metadata is great... but it kinda goes downhill after that. It would be fantastic if someone could update the documentation with more information and details. Just a side note, the code seems to be written as if it were intended to be written in C++ (even to comments talk about it as if it were), so why not just make it C++ and put a C frontend on it? -Gravis ___ 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] Questions about FLAC documentation
FlacNetLib was by far the most useful code reference. if you dont know object oriented programming then you need to muddle through libFLAC as i havent seen any other implementation that isnt OO. -Gravis On Sun, Nov 4, 2012 at 1:16 PM, Serban Giuroiu giur...@gmail.com wrote: Hi, Gravis. I'm trying to build a FLAC encoder from scratch. Besides the official format specification, people have mentioned some different decoder implementations in this thread including the reference decoder, J-Ogg, and FlacNetLib. I'm wondering if you found any other resources that were useful to you. Thanks! Serban On Oct 6, 2012, at 2:01 AM, Gravis f...@adaptivetime.com wrote: I'm implementing a FLAC decoder from scratch (save OGG stuff if I can help it) because libFLAC simply will not fit my embedded platform, For the most part I'm implementing using just the documentation but not all of the documentation is concise (especially about variable sized fields) and after looking at the libFLAC source I find myself befuddled so I thought it best to get the information from the people who know these things. So... In FRAME_HEADER there is a field of a variable size field with the description if(variable blocksize) \n 8-56 : 'UTF-8' coded sample number (decoded number is 36 bits) and I find the encoding scheme is somehow alien (I can't figure out what it has to do with UTF-8) and it's two following fields to be incomprehensible. There doesn't seem to be any information indicating their purpose either. The location and coding of audio samples is very nebulous in that I don't know where they are or the specifics of how any of their encoding scheme work. More details, links to more information and maybe even some pseudo code would be very helpful. The documentation about the metadata is great... but it kinda goes downhill after that. It would be fantastic if someone could update the documentation with more information and details. Just a side note, the code seems to be written as if it were intended to be written in C++ (even to comments talk about it as if it were), so why not just make it C++ and put a C frontend on it? -Gravis ___ 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] Shared library won't build when cross-compiling.
I'm having trouble cross-compiling FLAC for Windows from Linux. I am using the following commands: ./configure --host=i686-w64-mingw32 --prefix=/usr/i686-w64-mingw32 --enable-shared make The process completes successfully but I only end up with the static library. The following files are copied to the $(PREFIX)/lib directory when I run 'make install': - libFLAC.a - libFLAC++.a - libFLAC.la - libFLAC++.la ...and there aren't any DLLs in the $(PREFIX)/bin directory. Am I doing something wrong? - Nathan ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Flac HiRes decoding problems
Hi Eric. On Tue, Feb 28, 2012 at 7:57 AM, Erik de Castro Lopo mle...@mega-nerd.comwrote: Hi Klaus, I'm not really sure where to start with this one. Klaus Schulz wrote: My first post over here. While working on a music server optimzation (which ususally goes hand in hand with running pretty low buffers on realtime streams) I figured that certain HiRez flacs were causing XRUNS/hickups on my Linux server platform. What is a HiRez flac? How does it differ from a regular flac? HireRez flac 16/48e.g. 24/96 flacs. Decoding demands are somewhat different from 44/16 especially if a high compression level on 24/96 is used and the file gets decoded in realtime. The subject is probably about realtime decoding efficiency. It's probably not that easy to trace this down. The flac application is used as a realtime decoder to stdout (pipe) in a typical Squeezebox server setup. As I said. People reporting ( me to) running into hickups when streaming e.g. level 8 24/96 hirez-flacs. Getting them down to compression level 0 solved some issues. It happened always on the some tracks. I'm not sure what happens. Perhaps a buffer underrun on the receiving end of flacs stdout stream under certain conditions. One idea that came up: When reading the flac instruction page I do have the feeling that those instructions and aliases are still made for =16/48. The first thing that hit my eyes was the thing about different blocksizes to be used for material =48khz. The whole world is using those standard compression level aliases which wouldn't be in line with the blocksize recommendations for HiRez. I'm wondering what the most efficient ( related to decoding performance and NOT compression factor ) parametrization for a 24/96 file would be. I'd like to give that a try. The interesting thing is to run into XRUNS even though the stream gets send to a Squeezebox Touch which got a 20s buffer on its receiving end. XRUNS are a kernel/music player thing and not really anything to do with the FLAC library. I know. At least not directly. It's the pipe which breaks. The flac library ( or better the flac(.exe) applications could have some inefficiencies built in that show up on highly demanding HireZ realtime decoding. In order to better understand this issue, you need to separate the decoding from the playback. Do you have two files, one which rarely/never displays the problem and one which usually/always displays the problem? Are you able to post those files to a public website where I can retrieve them and test them? I think I'm not allowed to post them. Copyright. Is there a way to debug certain issues? Klaus 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] Information about the 8 channels
Hello, I'm very interested to know how are framed 8 different channels (not 5.1) in the FLAC format. Could you please explain this point and also if it is possible to extend the 8 channels to N channels as expressed in the FLAC Website (using Ogg container) ? How do you use Ogg and FLAC together in this purpose ? Can the 8 channels be easily decoded in a web browser (as Google Chrome) ? Many thanks for your answers ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Status of flac; new release?
On 12.12.2012, at 20:10, Ralph Giles wrote: On 12-12-12 10:47 AM, Max Horn wrote: If you point me to the sources of the site (is there a repos for it?), I'll be happy to provide a patch for this, too! The new site repo is https://git.xiph.org/flac-website.git Hum. Actually, I just noticed that the website is also in the flac repos itself, under doc/html/ The nasty part is: They differ in a lot of ways. Indeed, the one inside flac.git claims to be newer (last updated 2009) than the one in flac-website (last updated 2007?). On the other hand, download.html in flac.git links to flac-1.2.1a.exe while ine flac-website.git it links to flac-1.2.1b.exe -- still, I wonder if there are other discrepancies? Now, let's suppose we review the changes and merge them over if necessary (I assume this should be doable by going back to the head revision of flac-website.git, before any cleanups; easy enough). Several questions pop up: 1) Do you prefer to keep the website in a separate repository, as it is now? If yes, the copy in flac.git/doc/html should be removed. If no, flac-website.git should be removed. 2) In either case, the history should be consolidated: Either by suitable cherry picking / grafting the recent flac-website.git history over flac.git. Or else by re-creating flac-website.git: First, use git filter-branch to make a copy of the flac.git/doc/html dir with full history (but with that dir as root dir), then graft the handful commits of flac-website.git atop that. I have experience doing that and can be of assistance, if so desired. 3) What about the doxygen generated API docs? Keeping a static copy as in flac-website.git is not a good solution... One way would be to just remove the API docs from git completely, and rely on running doxygen on the webserver, perhaps by a cron job. Or perhaps you want to have it in the repository. If flac-website.git is abolished, that is easy enough to do. If flac-website.git is kept, then a way to achieve this would be to use the git submodule feature to place a copy of flac-website into flac.git/doc/html ... although this would somewhat defeat the idea behind keeping the website separate. (Personally, I think generated doxygen docs should not be part of the repos, but that's just me). Cheers, Max ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Shared library won't build when cross-compiling.
Nathan Osman wrote: I'm having trouble cross-compiling FLAC for Windows from Linux. I don't think this is working at the moment. Its on my list of things to fix before the next release. 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] Status of flac; new release?
On 13.12.2012, at 00:38, Ralph Giles wrote: On 12-12-12 2:56 PM, Max Horn wrote: Hum. Actually, I just noticed that the website is also in the flac repos itself, under doc/html/ How about that. I hadn't noticed that either! ;-). OK, so I had a closer look at the differences between the two. For this, I compared the first revision of flac-website.git (presumably obtained from web scrapping) with what is in flac.git. After removing some trivial differences (e.g. copyright 2008,2009), at least the following noteworthy differences remain (possibly more, but I need to get some sleep now ;). * flac.git changelog.html has an unfinished entry for 1.2.2, presumably listing not-yet-released changes. Perhaps this can be salvaged for the actual next release? * in flac.git, documentation_tools_flac.html is newer and documents Wave64 RF64 support, and also flac_options_preserve_modtime among other things * flac-website.git has newer comparison pages which have images, while flac.git does not * Tons of other stuff in flac.git seems to be outdated compared to the website (even though flac.git bears a *newer* copyright date... weird... makes me wonder if Josh at some point stopped using the repository for tracking the website? Or perhaps we did not get the latest version of the website from the CVS repos??) * in flac-website.git, local hyperlinks are changed from a href=#ANCHOR to a href=SOMEPAGE.html#ANCHOR I guess this is an artefact of web scraping, and I'd like to return this to the former version. This can be done with a simple script, though. (Personally, I think generated doxygen docs should not be part of the repos, but that's just me). No disagreement there. As for which repo to keep the site in, I don't feel too strongly. Whatever Erik prefers I guess. We should definitely merge the histories though. OK. The next thing then would be to determine how to move on with the website from a technical point of view. Right now, there is a lot of code duplication, in terms of common headers/footers on all pages. This should be resolved to make maintenance. The question is how exactly. This depends on what Erik wants, resp. on who is going to maintain the website on a regular basis -- they should be comfortable with whatever tools are chosen. Martijn suggested PHP, which is OK for basic stuff, I guess, and it would do the job. Although these days I personally try to avoid it (see also http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ ;-). But whatever works... Myself, I like tools that generate static pages, like http://middlemanapp.com/. There are zillions of alternatives, too :-). Once some format is chosen, the content (and if desired, looks) can be updated in full earnest. I'll be happy to help updating the content (but not with the layout, I suck at graphics design ;-). Here are some random things I noticed that should be updated, content wise: * The download and license pages contain this: If you would like to redistribute parts or all of FLAC under different terms, contact Josh Coalson. with a link to Josh' email address. I'd either remove this, or change it to point to flac-dev. [Legal perspective: Josh would have to agree to any alternative licensing, but so would any other source contributor. It's usually not worth the hassle anyway...] * The copyright blurb on all pages should be updated. Instead of listing years, give a range: Copyright (c) 2004,2005,2006,2007,2008 Josh Coalson becomes Copyright (c) 2004-2008 Josh Coalson (or -2009 if one believes flac.git). One could then add a (c) 2012 xuz where xyz are the persons who work on the website. Easier might be xyz = The FLAC team but that would require defining The FLAC team somewhere. * get rid of the outdated russian translation. If translation are desired, then this should be redone in a sane way * there are zillions of links on both the downloads and links page. Many of these are outdated, many modern ones are missing. Unless somebody here is hot on maintaining these lists, I would propose removing this and instead link to http://en.wikipedia.org/wiki/List_of_hardware_and_software_that_supports_FLAC. But no matter what: The flac download page should only link to official flac source tarballs and binaries, and perhaps a some 3rd party distributions (say, to the debian ubuntu packages, the Fink/MacPorts/Homebrew Mac packages, etc.). But not to arbitrary GUI frontends, commercial software etc. -- such links should be on the links.html page, if at all. * on the developers page, references to CVS should be replaced by git. Cheers, Max ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Shared library won't build when cross-compiling.
El 22/08/12 04:03, Nathan Osman escribió: I'm having trouble cross-compiling FLAC for Windows from Linux. I am using the following commands: ./configure --host=i686-w64-mingw32 --prefix=/usr/i686-w64-mingw32 --enable-shared make The process completes successfully but I only end up with the static library. The following files are copied to the $(PREFIX)/lib directory when I run 'make install': - libFLAC.a - libFLAC++.a - libFLAC.la - libFLAC++.la ...and there aren't any DLLs in the $(PREFIX)/bin directory. Works for me... -=-=-=-=-=-=-=-=-=-= Configuration Complete =-=-=-=-=-=-=-=-=-=- Configuration summary : FLAC version : 1.2.1 Host CPU : x86_64 Host Vendor : . w64 Host OS : . mingw32 Compiler is GCC : . yes GCC version : . 4.7.0 ls src/libFLAC/.libs/libFLAC-8.dll -rwxr-xr-x 1 crrodriguez users 1,3M dic 12 21:49 libFLAC-8.dll What compiler and flac version are you using ? ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] The FLAC website
On 14 September 2012 18:01, Martijn van Beurden mva...@gmail.com wrote: Hi all, I've updated the RSS feed and made the pages fetch and display that feed. Now only the feed had to be updated to update the pages as well. I have included a patch, however, I've never worked with git before so I hope everything is done correctly. If not, please tell me. I've removed the feeds/news-atom1.xml file, however that doesn't show up in the diff file? I would like to refresh the rest of the website as well, but changing the menu (to remove the russian part of the website for instance) requires to update all the pages, of which there are quite a lot. With my own website, I use PHP includes to keep a single 'header' and 'footer' file which is included in every page to keep updates easy. Would that be possible here as well? Does Xiph run on PHP? Are there other methods of 'including' a single header/footer that are preferable over PHP includes? IIRC the xiph sites use server-side includes (apache SSI) for headers and footers. I can't see the logs right now, but I vaguely recall that someone started porting the flac site to use the usual xiph include style, and that version is in SVN at: http://svn.xiph.org/websites-new/flac.xiph.org/ perhaps that would be a good place to start, and co-ordinate with the xiph.org webmaster about getting the new version installed. cheers, Conrad. On 30-08-12 21:46, Erik de Castro Lopo wrote: Sorry, for the late repsonse Martijn. I've been crazy busy. Martijn van Beurden wrote: On 28-08-12 10:46, Erik de Castro Lopo wrote: I think thats a great idea. WOuld be happy to have someone pick this up and run with it. So I got busy but stumbled upon several things. I'm not sure why there are two boxes displaying the same news on the homepage right now, so I made two screenshots of possible designs, one which keeps both boxes and one that moves everything to the sidebar. I've enlarged the sidebar a bit in both. http://www.icer.nl/images/ktf/flac-website-both.png http://www.icer.nl/images/ktf/flac-website-sidebar.png The design changed a little because I couldn't get everything exactly the same, which I assume isn't much of a problem. Its not. Anyway, I've updated the feed from the ancient atom format to the now standard RSS 2.0 spec, made some XSL-files to transform this feed to different lay-outs and googled some javascript to embed it into the website and added some search results for 'FLAC-news' :) Any thoughts about this lay-out? :) Sorry, no. Happy if you're thinking about and working on it :-). 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
