Re: [flac-dev] METADATA_BLOCK_PICTURE indexed-color field
I think it makes the most sense to consider these fields informational. So a programme might display it in a 'properties' panel, or use it to label the image in an index, or even use it to choose which picture to display when there are multiple options. But it can't really be used for critical decisions, like allocating an buffer to receive the decoded image. Any time you have a header with duplicate information like this (the same information is usually available in the image data stream) then the copy in the header can be incorrect, and players have to handle that by either rejecting the file (unfriendly unless everyone does it) or picking which one to expect. As Martijn says, figuring this out for gif is work, and even for png the flac code indicates it's not as easy as you'd think. Indexed image *displays* (as opposed to image files) are also rare these days, so getting it right isn't critical. The SHOULD distinction compared with MUST for the width and height probably reflect this. It looks like the flac code tries, but punts when determining an accurate count is complicated. Copying this code, or doing something similar based on your own project's image decoders should be fine. IMHO, Ralph On Wed, 2021-07-07 at 15:05 +0200, Martijn van Beurden wrote: > Op ma 5 jul. 2021 om 15:07 schreef leo60228 : > > I'm not clear on the utility of this. Do any programs made use of > > it? > > What do they use it for? > > It's hard to tell whether any program uses this. The manual says > > Otherwise, you must specify the width in pixels, height in pixels, > and > color depth in bits-per-pixel. If the image has indexed colors you > should also specify the number of colors used. When manually > specified, it is not checked against the file for accuracy. > > It says should, where it says color depth must be specified. I cannot > find out how FLAC actually sets this by itself. Maybe you can > decipher > this bit of code to find out: > https://github.com/xiph/flac/blob/master/src/share/grabbag/picture.c#L259 > ___ > 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] make fullcheck fails
On 2015-02-23 1:05 AM, lvqcl wrote: fullcheck: - (cd test make fullcheck) + (cd test make check) Or just - fullcheck: - (cd test make fullcheck) + fullcheck: check -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] Update website
On 2014-11-28 12:23 PM, Martijn van Beurden wrote: Finally, I'd like to point out that the sourceforge page still has flac-1.2.1b.exe marked as default download for Windows visitors. So, while visitors on Linux sees flac-1.3.1-win.zip, visitors on Windows do not. AFAIK this can be fixed by someone with sourceforge admin rights for the FLAC project going to files - flac-win - flac-1.3.1-win, clicking the i-icon at the right side of the table, ticking the box in front of the Windows icon and pressing save :) I have done this, and now on Windows I am offered flac-1.3.1-win.zip. I also uploaded the 1.3.0 and 1.3.1 tar.xz source packages and set flac-1.3.1.tar.xz as the default for other operating systems. Thanks for the instructions! -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] Re: [flac:bugs] #420 flac make check fails on os x
On 2014-11-25 9:29 PM, Erik de Castro Lopo wrote: I've applied a variant of Mark Harris' patch from sf.net. Confirmed. 'make check' works on Mac for me now. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] [PATCH] Re: [flac:bugs] #420 flac make check fails on os x
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2014-11-24 9:49 PM, mark4o wrote:
$ make check ... Original file size 441044 bytes. Compression
level 0, file size 421389 bytes. ./test_compression.sh: line 42:
let: last_size=: syntax error: operand expected (error token is
=)
I can reproduce on MacOS X 10.8.5. It doesn't seem to like the
assignment inside the let statement. Possible an issue with the older
bash (3.2) Apple ships?
The attached patch resolves the issue, and I believe does the same
thing. Martin, does this look correct to you?
-r
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCAAGBQJUdPRKAAoJEEcAD3uxRB3vxfEH/A75c5UycOYpnC06Kz9f9KM8
xjzWFfVaB8Fl0X7F586BkyRgmwJQK+NrLkb2FR4+m0MdTvpywpVrKSF9KjDc6p5x
ruuQSYJje1X8D4mIR/BeZZUJHtY7YIVIOnPoBfocn1lDtd/pEM4gUZxcaH9p5NWZ
GACOtdBOYh56RbH86AX5wbWuPADFnUTo2/09zME/3y4q1mPLjuZ5jOhPc3G82s+J
kRZSwxAKCE0jTtyk0qVraHOzU3bE2Et9FtbkWjeosEvS9O3bgj1aH+q5+Trhm+mb
6PPWi7npVVunoXfRrWyQieSTBJFrgboL6fYOfr3nOIu+GqJM4z5QQ/jARUwaaaI=
=jc02
-END PGP SIGNATURE-
From f4547f06f710910059d173990efb99dc77917ed9 Mon Sep 17 00:00:00 2001
From: Ralph Giles gi...@thaumas.net
Date: Tue, 25 Nov 2014 13:21:30 -0800
Subject: [PATCH] Use arithmetic compound syntax instead of 'let'.
Fixes a synax error with 'make check' on MacOS X.
I also fixed the eccentric indent.
---
test/test_compression.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/test/test_compression.sh b/test/test_compression.sh
index 022ff8e..7507024 100755
--- a/test/test_compression.sh
+++ b/test/test_compression.sh
@@ -38,8 +38,8 @@ for k in 0 1 2 3 4 5 6 7 8 ; do
if test ${last_size} -lt ${size} ; then
echo Error : Compression ${last_k} size $last_size =
compression $k size $size.
exit 1
- fi
- let last_size=${size}+10
+ fi
+ ((last_size=${size}+10))
last_k=${k}
rm -f ${fname}
- done
+done
--
1.8.5.2 (Apple Git-48)
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] New release
On 2014-11-23 3:01 AM, Janne Hyvärinen wrote: At least Windows users expect to find official version at https://xiph.org/flac/download.html. Right now it links to old sourceforge page http://sourceforge.net/projects/flac/files/flac-win/ that only has version 1.2.1. Is this just a static build of the 'flac' command-line tool? I can do that for 1.3.0 and 1.3.1, or we can do a cross-build with gcc on Linux. On MacOS X, flac is available through homebrew, and I've been maintaining that. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] free() invalid pointer
On 2014-11-13 6:47 AM, Martijn van Beurden wrote: I haven't been able to reproduce this on x86_64, so using Valgrind is not possible I guess? Valgrind does have some armv7 support now, so it's possible to use it to track down these things. -fsanitize=address has some arm support as well. FWIW, -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] form feed in getopt
On 2014-11-13 7:49 AM, lvqcl wrote: I found that getopt.c and getopt1.c files contain 0x0c character aka form feed aka '\f'. What's the purpose of them? GNU code (or emacs?) sometimes uses ^L as a page break. It's reasonable to remove them. The compiler treats them as whitespace, so it's only an issue of formatting style. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] [PATCH] Add configure check for bswap16
The gcc version #ifdef fix for bswap16 doesn't work for Apple's clang.
Here's a better fix, which has configure check for it directly.
Fixes build failures on MacOS X.
-r
From 05445ca46da8c1c118c8ec3ba34df8ca0f76925d Mon Sep 17 00:00:00 2001
From: Ralph Giles gi...@thaumas.net
Date: Tue, 4 Nov 2014 11:57:28 -0800
Subject: [PATCH 1/4] Add autoconf macro to check for the bswap16 intrinsic.
---
m4/bswap.m4 | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/m4/bswap.m4 b/m4/bswap.m4
index 926f820..72af333 100644
--- a/m4/bswap.m4
+++ b/m4/bswap.m4
@@ -1,4 +1,4 @@
-dnl Copyright (C) 2012 Xiph.org Foundation
+dnl Copyright (C) 2012-2014 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
@@ -53,3 +53,30 @@ AC_DEFUN([XIPH_C_BSWAP32],
)]
)# XIPH_C_BSWAP32
+
+
+dnl @synopsis XIPH_C_BSWAP16
+dnl
+dnl @author Erik de Castro Lopo er...@mega-nerd.com
+dnl
+dnl Dtermine whether the compiler has the __builtin_bswap16() intrinsic which
+dnl is likely to be present for most versions of GCC as well as Clang.
+
+AC_DEFUN([XIPH_C_BSWAP16],
+[AC_CACHE_CHECK(for bswap16 instrinsic,
+ ac_cv_c_bswap16,
+
+ # Initialize to no
+ ac_cv_c_bswap16=no
+ HAVE_BSWAP16=0
+
+ [AC_TRY_LINK([],
+return __builtin_bswap16 (0) ;,
+ac_cv_c_bswap16=yes
+HAVE_BSWAP16=1
+ )]
+ AC_DEFINE_UNQUOTED(HAVE_BSWAP16, ${HAVE_BSWAP16},
+[Compiler has the __builtin_bswap16 intrinsic])
+
+ )]
+)# XIPH_C_BSWAP16
--
1.8.5.2 (Apple Git-48)
From 0d4ae3ea6a49df3eb5a1df1ba6550fd1b613579e Mon Sep 17 00:00:00 2001
From: Ralph Giles gi...@thaumas.net
Date: Tue, 4 Nov 2014 11:58:45 -0800
Subject: [PATCH 2/4] Use a configure check for bswap16 instead of gcc version
#ifdefs.
Fixes a build problem on apple clang.
---
configure.ac| 1 +
include/share/endswap.h | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index dae619e..3ed4e7f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,6 +67,7 @@ AC_CHECK_HEADERS([stdint.h inttypes.h byteswap.h sys/param.h
termios.h x86intrin
AC_HEADER_TIOCGWINSZ
XIPH_C_BSWAP32
+XIPH_C_BSWAP16
ac_cv_c_big_endian=0
ac_cv_c_little_endian=0
diff --git a/include/share/endswap.h b/include/share/endswap.h
index 86bf857..dece49c 100644
--- a/include/share/endswap.h
+++ b/include/share/endswap.h
@@ -34,7 +34,7 @@
#if HAVE_BSWAP32 /* GCC and Clang */
/* GCC prior to 4.8 didn't provide bswap16 on x86_64 */
-#if __GNUC__ = 4 __GNUC_MINOR__ 8
+#ifndef HAVE_BSWAP16
static inline unsigned short __builtin_bswap16(unsigned short a)
{
return (a8)|(a8);
--
1.8.5.2 (Apple Git-48)
From 55c8e0b2a1c73ffde8c907b39abee08161ccc429 Mon Sep 17 00:00:00 2001
From: Ralph Giles gi...@thaumas.net
Date: Tue, 4 Nov 2014 11:59:53 -0800
Subject: [PATCH 3/4] Clean up bswap32 autoconf macro.
Improve 'checking' message and don't hog the cache namespace.
---
m4/bswap.m4 | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/m4/bswap.m4 b/m4/bswap.m4
index 72af333..eec3ee1 100644
--- a/m4/bswap.m4
+++ b/m4/bswap.m4
@@ -36,16 +36,16 @@ dnl Dtermine whether the compiler has the
__builtin_bswap32() intrinsic which
dnl is likely to be present for most versions of GCC as well as Clang.
AC_DEFUN([XIPH_C_BSWAP32],
-[AC_CACHE_CHECK(has bswap32 instrinsic,
- ac_cv_c_bswap,
+[AC_CACHE_CHECK(for bswap32 instrinsic,
+ ac_cv_c_bswap32,
# Initialize to no
- ac_cv_c_bswap=no
+ ac_cv_c_bswap32=no
HAVE_BSWAP32=0
[AC_TRY_LINK([],
return __builtin_bswap32 (0) ;,
- ac_cv_c_bswap=yes
+ ac_cv_c_bswap32=yes
HAVE_BSWAP32=1
)]
AC_DEFINE_UNQUOTED(HAVE_BSWAP32, ${HAVE_BSWAP32},
--
1.8.5.2 (Apple Git-48)
From 0b2f5b4bef8116b27660e24597e915c9fbf2b828 Mon Sep 17 00:00:00 2001
From: Ralph Giles gi...@thaumas.net
Date: Tue, 4 Nov 2014 12:01:48 -0800
Subject: [PATCH 4/4] Fix indenting on the bswap32 autoconf macro.
We generally prefer spaces to tabs.
---
m4/bswap.m4 | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/m4/bswap.m4 b/m4/bswap.m4
index eec3ee1..e6793d6 100644
--- a/m4/bswap.m4
+++ b/m4/bswap.m4
@@ -37,21 +37,21 @@ dnl is likely to be present for most versions of GCC as
well as Clang.
AC_DEFUN([XIPH_C_BSWAP32],
[AC_CACHE_CHECK(for bswap32 instrinsic,
- ac_cv_c_bswap32,
+ ac_cv_c_bswap32,
- # Initialize to no
- ac_cv_c_bswap32=no
- HAVE_BSWAP32=0
+ # Initialize to no
+ ac_cv_c_bswap32=no
+ HAVE_BSWAP32=0
- [AC_TRY_LINK([],
- return __builtin_bswap32 (0) ;,
- ac_cv_c_bswap32=yes
- HAVE_BSWAP32=1
- )]
- AC_DEFINE_UNQUOTED
Re: [flac-dev] Lets work towards a new version
On 2014-06-19 6:01 AM, Erik de Castro Lopo wrote: Ok, Audacity is not a good example to follow. We need to find out what some other common used cross platform project is doing. Preferably more than one project. FWIW, the other xiph codecs have parallel sets of MSVC project files under the win32 directory. We did this because while newer versions can generally open/update older project files, the reverse is true and many developers said they weren't upgrading. libogg has separate project files for VS2003, VS2005, VS2008, VS2010, and VS6. That said, for Opus we've only been maintaining VS2010 project files (tested with both VS2010 and VS2013 Express) and haven't had any complaints. I'd suggest a single set of project files which work with a previous but recent release of the free Visual Studio Express, and see if that works for people. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] ogg_mapping.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-05-03 1:52 AM, LRN wrote: Why is ogg_mapping.c full of variables? Why not macros? I didn't write it, but generally one does this because const globals are as efficient as macros, but you get type checking and normal interactions with operator precedence. -r -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTZQyiAAoJEEcAD3uxRB3vbAYH/R/crlCIutUozkavrVSvQOms WLPTFF5KQu434qKzX5YDR8gCiYn1qOJLnQHNGSKw7mtbl0N3wpWrawZA75gohbmn jq3M03q6c5s3ug3R0EnWov5/CAsLOzWz4aKgn+thA1P7vsyDSqNZ53PtNlQUPOlT ibV2mhncxlN6f4oijBPjtbhgVNaBmvpKEpvAyFa7HXBXzgd6+pweIpEix893HQdT TOtNdn7ttfQudOKpYfvWldCKqppj6PCrJScKn/NJTHP7dZK5b3wPDKRjxJvZDdjs LPS+r9QtOAALbKotoO3vi5qrVnjNjKUZbDImzP6hZScqOvfYtUpRqHdwnrYI4Rg= =T0tn -END PGP SIGNATURE- ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] MSVS: debug flac.exe uses release libogg_static.lib
On 2013-09-30 4:53 PM, Erik de Castro Lopo wrote: I'd be keen to have the windows build automatically do the sanest possible thing, preferably with anyone having to copy files. The way we've been doing the Opus stuff is to have the project files expect a build in a parallel checkout. so: c:\dev\flac\FLAC.sln expects to find an ogg build in c:\dev\ogg\win32\VS2010\ Not as obvious as having a monolithic build, but it seems to work once you've figured it out. And each arch and target can reference the corresponding target in the dependency. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] MSVS: debug flac.exe uses release libogg_static.lib
On 2013-09-29 2:14 AM, lvqcl wrote: With current settings, MSVS links debug version of flac.exe (and other .exe and .dll files) with the release version of libogg_static.lib. MSVS issues a warning LNK4098: defaultlib 'libcmt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library What's the reason in this setting? Sounds like a bug. Debug targets should link to debug builds of their dependencies to simplify debugging. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Closing sf.net issue tracker
On 13-08-19 3:54 AM, Erik de Castro Lopo wrote: All the winamp2 bugs can be ignored because upstream winamp already contains FLAC support and we dropped the plugin from the sources some time ago. Ok, thanks. I'll just close those without forwarding. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] sf bug 258 - don't calloc pointers
Bug suggests using literal assignment to initialize pointers in structures instead of calloc, to avoid pointer-representation assumptions. https://sourceforge.net/p/flac/bugs/258/ Pointers should not be initialised by the function calloc if they are a member of a bigger data structure. Would you like to deal with an internal representation that is not all-bits-0? http://c-faq.com/null/varieties.html I recommend to assign a 0 to data elements like buffer in the functions FLAC__bitreader_new and FLAC__bitwriter_new separately. http://flac.cvs.sourceforge.net/flac/flac/src/libFLAC/bitreader.c?revision=1.6view=markup http://flac.cvs.sourceforge.net/flac/flac/src/libFLAC/bitwriter.c?revision=1.8view=markup Are assignments for the data element words in the functions FLAC__bitreader_init and FLAC__bitwriter_init unnecassary in this context? ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Closing sf.net issue tracker
As part of the ongoing move of FLAC's project hosting from sourceforge.net to xiph.org, we're planning to remove the issue tracker there. Erik doesn't check it, so issues filed there are just rotting, and that's a poor experience. We don't have a decent alternative at xiph.org at the moment. We've variously discussed setting up a bugzilla instance or using github. In the meantime, Erik said he would like to track and triage issues just though the mailing list. I pursuit of that goal, I'll go through the open issues in the sf.net tracker and post them here, then close them as they're addressed by Erik. I hope that way we can take down the tracker without missing any reports. There are quite a few, so list traffic will be higher than normal for a bit. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] sf bug 84
User reported in 2003 output glitch in winamp2 when playing a 24-bit flac file after a 16-bit shn file. Possibly a winamp bug. Closed as out-of-date. https://sourceforge.net/p/flac/bugs/84/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] sf bug 98
User reported in 2003 that crossfading doesn't work in winamp2 between 44.1 and 48 kHz files. Closed as not our bug. https://sourceforge.net/p/flac/bugs/98/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] sf bug 136
User reported in 2005: I have recently upgraded to FLAC 1.1.1a and Winamp 5.06 and have noticed a bug in the winamp plugin. When using the Scroll Title in windows taskbar option in Winamp the title flickers in the taskbar and does not scroll. If I revert back to the Winamp plugin from 1.1.0 it works fine. To find this option in Winamp goto: Options/Preferences/General Preferences and tick Scroll Title in windows taskbar Can you please advise if this can be fixed :) https://sourceforge.net/p/flac/bugs/136/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] sf bug 113
User reported in 2004 that the 'FLAC info' dialog displayed by the winamp2 plugin doesn't provide enough space to work with the 'large font' setting. Closed as out-of-date. https://sourceforge.net/p/flac/bugs/113/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] (no subject)
On 13-05-02 7:37 PM, Marcus Johnson wrote: Here's the Flac.xcodeproj, compressed with 7-zip as it's just a folder and can't be transmitted without being compressed, check to see if it works on your computers, and hopefully everything works. .7z isn't a normal MacOS tool. Could you please send a tar.gz or .zip instead? -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Pre-release 1.3.0pre4 (hopefully the last)
On 13-04-30 2:45 PM, Martijn van Beurden wrote: http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre4.tar.xz This tarball passes 'make distcheck' on an armv7l pcduino (AllWinner A10) running Linaro 12.11 ubuntu variant. Likewise on an x86_64 running MacOS 10.7.5. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] (no subject)
On 13-05-01 3:45 PM, Marcus Johnson wrote: I've got the Xcode project done, I'm having trouble finding the proper format for the header search path, and do I need to include the tests in the xcodeproj? It's always better if you can include the self-tests, both for build verification and as example code. However, it's not essential. Unfortunately most IDEs don't have a concept of the 'make check' step, so it can be hard to set up in an obvious way. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] What is in directory flac.pbproj?
On 13-04-30 8:20 AM, Erik de Castro Lopo wrote: I should junk it then. Whatever is there now doesn't work. If someone wants to resurrect it they can always pull it out of git. Yes, that's fine. XCode 4.6.2 binds the extension, but can't open the project files, saying they're too old, so these aren't useful to current developers. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] flac 1.3.0pre1 prelease
On 13-03-02 3:22 PM, Erik de Castro Lopo wrote:
http://downloads.xiph.org/releases/flac/beta/
On Mac 10.7.5 Apple clang 4.2, 'make check' fails because BSD and GNU
coreutils have incompatible format options for 'stat'.
If I change test/test_compression.sh to use:
size=`stat -f %z ${fname}`
The self tests complete without error. Of course that won't work on a
GNU system. Stack overflow suggests 'wc -c' as a portable version:
size=`wc -c ${fname}`
Which does work on the Mac.
-r
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] [PATCH] support 7 and 8 channel wav files as input
Now that we've selected a channel mapping for 7 and 8 channel flac, the
command-line encoder tools needs updating to accept wav files with
compatible channel maps.
-r
From 34e72dcae28c443a4a83ba6da5e2334b4865c5ed Mon Sep 17 00:00:00 2001
From: Ralph Giles gi...@mozilla.com
Date: Thu, 17 Jan 2013 16:21:45 -0800
Subject: [PATCH] Add appropriate WAV channel masks for 7 and 8 channel files.
This commit accepts the new default channel masks for 6.1 and 7.1
surround input WAV files, and writes the corresponding masks when
decoding to WAV without a channel mask from the metadata block.
---
src/flac/decode.c | 5 +
src/flac/encode.c | 4 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/flac/decode.c b/src/flac/decode.c
index 98fc430..2d1bdd6 100644
--- a/src/flac/decode.c
+++ b/src/flac/decode.c
@@ -354,6 +354,11 @@ FLAC__bool DecoderSession_process(DecoderSession *d)
else if(d-channels == 6) {
d-channel_mask = 0x060f;
}
+else if(d-channels == 7) {
+d-channel_mask = 0x070f;
+}
+else if(d-channels == 8) {
+d-channel_mask = 0x063f;
}
/* write the WAVE/AIFF headers if necessary */
diff --git a/src/flac/encode.c b/src/flac/encode.c
index eeea08a..58cdc77 100644
--- a/src/flac/encode.c
+++ b/src/flac/encode.c
@@ -481,7 +481,9 @@ static FLAC__bool get_sample_info_wave(EncoderSession *e,
encode_options_t optio
channel_mask == 0x0037 || /* 5
channels: front left, front right, front center, back left, back right */
channel_mask == 0x0607 || /* 5
channels: front left, front right, front center, side left, side right */
channel_mask == 0x003f || /* 6
channels: front left, front right, front center, LFE, back left, back right */
- channel_mask == 0x060f/* 6
channels: front left, front right, front center, LFE, side left, side right */
+ channel_mask == 0x060f || /* 6
channels: front left, front right, front center, LFE, side left, side right */
+channel_mask == 0x070f || /* 7
channels: front left, front right, front center, LFE, back center, side left,
side right */
+channel_mask == 0x063f/* 8
channels: front left, front right, front center, LFE, back left, back right,
side left, side right */
) {
/* keep default channel order */
}
--
1.7.12.4 (Apple Git-37)
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] support 7 and 8 channel wav files as input
On 13-03-01 2:17 PM, Erik de Castro Lopo wrote:
Ralph, looks like there's a missing closing brace there. Do you want to fix
it and resubmit or should I fix it?
Sorry about that. Is this one better?
-r
commit 93d92eb5e98cacd8cab185a0bfdaafb795b14b22
Author: Ralph Giles gi...@mozilla.com
Date: Thu Jan 17 16:21:45 2013 -0800
Add appropriate WAV channel masks for 7 and 8 channel files.
This commit accepts the new default channel masks for 6.1 and 7.1
surround input WAV files, and writes the corresponding masks when
decoding to WAV without a channel mask from the metadata block.
The local copy of the format spec is also updated with the new text
from the flac-website repository.
diff --git a/doc/html/format.html b/doc/html/format.html
index a8a539e..87f6413 100644
--- a/doc/html/format.html
+++ b/doc/html/format.html
@@ -1247,11 +1247,11 @@
li1 channel: mono/li
li2 channels: left, right/li
li3 channels: left, right,
center/li
- li4 channels: left, right,
back left, back right/li
- li5 channels: left, right,
center, back/surround left, back/surround right/li
- li6 channels: left, right,
center, LFE, back/surround left, back/surround right/li
- li7 channels: not defined/li
- li8 channels: not defined/li
+ li4 channels: front left,
front right, back left, back right/li
+ li5 channels: front left,
front right, front center, back/surround left, back/surround right/li
+ li6 channels: front left,
front right, front center, LFE, back/surround left, back/surround right/li
+ li7 channels: front left,
front right, front center, LFE, back center, side left, side right/li
+ li8 channels: front left,
front right, front center, LFE, back left, back right, side left, side
right/li
/ul
/li
li
diff --git a/src/flac/decode.c b/src/flac/decode.c
index 98fc430..77acb7c 100644
--- a/src/flac/decode.c
+++ b/src/flac/decode.c
@@ -354,6 +354,12 @@ FLAC__bool DecoderSession_process(DecoderSession *d)
else if(d-channels == 6) {
d-channel_mask = 0x060f;
}
+else if(d-channels == 7) {
+d-channel_mask = 0x070f;
+}
+else if(d-channels == 8) {
+d-channel_mask = 0x063f;
+}
}
/* write the WAVE/AIFF headers if necessary */
diff --git a/src/flac/encode.c b/src/flac/encode.c
index eeea08a..58cdc77 100644
--- a/src/flac/encode.c
+++ b/src/flac/encode.c
@@ -481,7 +481,9 @@ static FLAC__bool get_sample_info_wave(EncoderSession *e,
encode_options_t optio
channel_mask == 0x0037 || /* 5
channels: front left, front right, front center, back left, back right */
channel_mask == 0x0607 || /* 5
channels: front left, front right, front center, side left, side right */
channel_mask == 0x003f || /* 6
channels: front left, front right, front center, LFE, back left, back right */
- channel_mask == 0x060f/* 6
channels: front left, front right, front center, LFE, side left, side right */
+ channel_mask == 0x060f || /* 6
channels: front left, front right, front center, LFE, side left, side right */
+channel_mask == 0x070f || /* 7
channels: front left, front right, front center, LFE, back center, side left,
side right */
+channel_mask == 0x063f/* 8
channels: front left, front right, front center, LFE, back left, back right,
side left, side right */
) {
/* keep default channel order */
}
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Beginner's question
On 13-02-08 11:31 AM, Johnny Rosenberg wrote: I'm not very familiar with creating projects with dedicated IDEs, so far I only use a simple text editor and I want to keep it that way for a while, if possible. If you've installed libflac-dev you should be able to compile the example code against the system library. What's missing from that directory as the build files, which you probably don't want to use because they depend on building the flac library itself. From the command line, try something like: cc -g -o example main.c -lFLAC -lm Which will compile a debug version of main.c, link it to the system libflac and libm, and create an executable called 'example'. Good luck with your programming efforts, -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Anyone tried building FLAC with MSVC?
On 13-01-24 2:10 PM, Martijn van Beurden wrote: 6) Replace all occurrences of static inline with static __inline This should be done with a global define for 'inline'. 7) Tell the linker to ignore msvcrt.lib Visual Studio tells you to do this, but it's wrong. This probably comes from the libogg and flac projects using different runtime libraries. Make sure you're using release ogg with release flac, and if it still complains, change one of the projects to match the other.j Thanks for trying out the project files! -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] [PATCH] fix leftover files blocking 'make distcheck'
This unbreaks 'make distcheck' for me. Jenkins shows this stopped working with f1841caba3. -r From 8790911d77f857f410c6029ddb7d1f987e47ba6f Mon Sep 17 00:00:00 2001 From: Ralph Giles gi...@mozilla.com Date: Fri, 18 Jan 2013 14:04:27 -0800 Subject: [PATCH] Fix the 'distclean' target. Generated documentation needs to be removed by this target for 'distcheck' to succeed. --- doc/Makefile.am | 2 +- doc/html/Makefile.am | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/Makefile.am b/doc/Makefile.am index 67703e9..54ec270 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -38,5 +38,5 @@ doc_DATA = \ EXTRA_DIST = Doxyfile.in Makefile.lite doxygen.footer.html doxygen.header.html $(doc_DATA) -maintainer-clean-local: +distclean-local: rm -rf FLAC.tag html/api doxytmp diff --git a/doc/html/Makefile.am b/doc/html/Makefile.am index 2b06aab..5fd97cc 100644 --- a/doc/html/Makefile.am +++ b/doc/html/Makefile.am @@ -75,6 +75,6 @@ install-data-local: (cd $(builddir)/api $(INSTALL_DATA) * $(DESTDIR)$(docdir)/api) uninstall-local: rm -rf $(DESTDIR)$(docdir)/api -maintainer-clean-local: - rm -rf api +distclean-local: + -rm -rf api endif -- 1.7.11.7 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Tag flac as flac 1.2.1_git
On 13-01-16 11:10 PM, Erik de Castro Lopo wrote: My understanding is that the recent changes for 7 and 8 channels was a documentation change only. I think we should also change the flac front-end utility to construct and interpret the WAVE channel mask for 7 and 8 channel files. No one has written that patch yet. FWIW I generally agree with Erik that 1.3.x is justified by the long period without a point release. Adding a channel mapping for 7 and 8 channel files is a small spec addition, and doesn't have a serious effect on deployed implementations. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Define 6.1 and 7.1 channel mappings
On 13-01-01 4:36 PM, Tim W. wrote:
- 4 channels: left, right, back left, back right (FL FR BL BR)
- 5 channels: left, right, center, back/surround left, back/surround right
(FL FR FC BL BR or FL FR FC SL SR, same order so doesn't matter)
- 6 channels: left, right, center, LFE, back/surround left, back/surround
right
(FL FR FC LFE BL BR or FL FR FC LFE SL SR, same order so
doesn't matter)
I looked at the 'flac' command-line front-end code today, and it uses
Back Left and Back Right for 4 channel but Side Left and Side Right for
5 and 6 channel files when writing out WAVE from FLAC files without a
WAVFORMATEXTENSIBLE_CHANNEL_MASK metadata tag.
As you say, the order is the same, and for less that 7 channels the
physical speaker configurations are equivalent.
The encoder accepts both Side and Back in the input channel mask, but
passes them on in the tag, of course. If the input is AIFF the support
is more limited, rejecting any multichannel file unless the undocumented
--channel-map=none is passed, followed by some dead code saying only 1,
2, 3, and 5 channels can be unambiguously mapped.
- 6.1: FL FR FC LFE BC SL SR (L R C LFE Cs Ls Rs)
- 7.1: FL FR FC LFE BL BR SL SR (L R C LFE Rls Rrs Ls Rs)
Again, I'm suggesting we update the spec to define these as the default
channel maps for 7 and 8 channel FLAC files in the absence of the
overriding WAVFORMATEXTENSIBLE_CHANNEL_MASK metadata tag, and modify the
included 'flac' front-end to write out those masks when decoding such
files. Likewise, we would modify 'flac' to accept files with those
channel masks as input when encoding.
Untested patch attached.
-r
From 2473146aac0b1c00863692b15ae0588373a00b04 Mon Sep 17 00:00:00 2001
From: Ralph Giles gi...@mozilla.com
Date: Thu, 17 Jan 2013 16:21:45 -0800
Subject: [PATCH] Add appropriate WAV channel masks for 7 and 8 channel files.
This commit accepts the new default channel masks for 6.1 and 7.1
surround input WAV files, and writes the corresponding masks when
decoding to WAV without a channel mask from the metadata block.
---
src/flac/decode.c |7 +++
src/flac/encode.c |4 +++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/flac/decode.c b/src/flac/decode.c
index fa82c04..733b6e2 100644
--- a/src/flac/decode.c
+++ b/src/flac/decode.c
@@ -360,6 +360,13 @@ FLAC__bool DecoderSession_process(DecoderSession *d)
if(d-channel_mask == 0)
d-channel_mask = 0x060f;
}
+else if(d-channels == 7) {
+if(d-channel_mask == 0)
+d-channel_mask = 0x070f;
+}
+else if(d-channels == 8) {
+if(d-channel_mask == 0)
+d-channel_mask = 0x063f;
}
/* write the WAVE/AIFF headers if necessary */
diff --git a/src/flac/encode.c b/src/flac/encode.c
index eeea08a..58cdc77 100644
--- a/src/flac/encode.c
+++ b/src/flac/encode.c
@@ -481,7 +481,9 @@ static FLAC__bool get_sample_info_wave(EncoderSession *e,
encode_options_t optio
channel_mask == 0x0037 || /* 5
channels: front left, front right, front center, back left, back right */
channel_mask == 0x0607 || /* 5
channels: front left, front right, front center, side left, side right */
channel_mask == 0x003f || /* 6
channels: front left, front right, front center, LFE, back left, back right */
- channel_mask == 0x060f/* 6
channels: front left, front right, front center, LFE, side left, side right */
+ channel_mask == 0x060f || /* 6
channels: front left, front right, front center, LFE, side left, side right */
+channel_mask == 0x070f || /* 7
channels: front left, front right, front center, LFE, back center, side left,
side right */
+channel_mask == 0x063f/* 8
channels: front left, front right, front center, LFE, back left, back right,
side left, side right */
) {
/* keep default channel order */
}
--
1.7.10.2 (Apple Git-33)
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Define 6.1 and 7.1 channel mappings
On 13-01-17 7:26 PM, Brian Willoughby wrote: I vote for documenting the --channel-map option in the --help I suspect it's undocumented because 'none' is the only implemented argument, which is a way to work around the defined channel map signalling. I.e. it doesn't make interoperable files. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Define 6.1 and 7.1 channel mappings
On 13-01-17 7:26 PM, Brian Willoughby wrote: I vote for documenting the --channel-map option in the --help Do you ever use --channel-map yourself, or recommend it to clients? -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Information about the 8 channels
On 12-12-13 11:18 AM, Martin Leese wrote: Can the 8 channels be easily decoded in a web browser (as Google Chrome) ? I don't think Chrome or Firefox support FLAC decoding natively. There's been some discussion of native surround support in the context of the Web Audio spec recently. http://lists.w3.org/Archives/Public/public-audio/2013JanMar/0091.html -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Define 6.1 and 7.1 channel mappings
On 13-01-02 3:16 PM, Stephen F. Booth wrote: I think we may be butting up against an area where the standards aren't clear. That's the conclusion I came to. Earlier today I looked through http://read.pudn.com/downloads122/ebook/519453/EIA-CEA-861-B.pdf, which defines speaker configurations for HDMI, among other things. It uses rear left, rear left centre, rear centre, rear right centre, rear right instead of 'side' or 'surround' labels. So we now have three different sets of terminology just for the planar configurations! I think my preference for the Apple/Core Audio layouts is known but obviously any standard would be better than none. Do I understand correctly that WAVE_FORMAT_EXTENSIBLE simply defines a standard channel order and FLAC would specify compatible channel masks? That's what WAVE_FORMAT_EXTENSIBLE defines in the context of the WAVE file format and playback APIs on MS Windows. What Tim and I are proposing is a little simpler. I think that we should define 7 and 8 channel flac files to use a planar speaker configuration, with the additional channels in side/rear/surround positions (rather than the front) and that order of the channels to be as in Tim's option #1 and my original patch. This matches what Vorbis does, and as Tim says, is compatible with WAVE and would bless what tools based on libavcodec are doing today. Doing so provides enough information for players to mix the decoder output for any actual speaker arrangement. There aren't enough bits in the flac frame header to directly accommodate all of the speaker arrangements mentioned in the various standards, so for the purposes of that field we have to pick a particular set, just as was done with 5.1 audio. The flac specification says the channel mapping follows ITU standards where defined so I think we're ok choosing which of the available configurations to support for 6.1 and 7.1. If it is important to support other configurations, we could _in addition_ define an extension mechanism, e.g. with the WAVEFORMATEXTENSIBLE_CHANNEL_MASK in a vorbis comment or custom metadata block and have that override the default setting from the frame header. I don't think that's necessary for the use case we were addressing here, which is mastering 6.1 or 7.1 audio tracks for video. Remember also that flac streams are limited to no more than 8 channels, while much of the current experimentation with surround configuration uses rather more than that. I'm skeptical that going through all software and adding support for a handful of 7.1 layouts is useful in the long run. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] The FLAC website (+[PATCH])
On 13-01-01 12:17 PM, Martijn van Beurden wrote: Anyway, after some hassle, I finally got format-patch working as it should. I've updated the sourceforge tracker links, changed all cvs-links to link to the current git and added some news. Applied, thanks! For future patches, please set a valid email address for you commits with git config user.email 'mva...@gmail.com' or whatever. Also, the general convention with commit messages is to start with a one-line summary, then a double newline, then a more detailed description of the changes or motivation, all word-wrapped to 72 columns or less. This works better with established tools which extract the first line for commit summaries. I've added a newline to your commit message. I'm on it, but have a few questions: will the CVS repository (which is not updated anymore I guess?) be closed to avoid confusion? Is the Sourceforge bug and feature request tracker still used? The Sourceforge-stuff has to be updated as well. I'd like to leave the CVS repository online for another year or two to give a more gentle transition. I've added http://flac.cvs.sourceforge.net/viewvc/flac/flac/REPOSITORY_HAS_MOVED which points to the git repo so anyone still using that code will be informed of the move. We should just link to the git repo for normal development, of course. Xiph doesn't have a decent bug tracker, so we might as well keep using the sf.net one if people are willing to follow it. Erik, what would you prefer? -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Define 6.1 and 7.1 channel mappings
On 12-10-12 4:47 AM, Erik de Castro Lopo wrote: I've read through this thread and it didn't really come to any conclusion. Can we try again and make a decision this time? Anyone else have thoughts on this? I'd like to get this added before the 1.3.x release. Especially helpful would be research into what current tools actually do. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] The FLAC website
On 12-12-27 3:28 AM, Erik de Castro Lopo wrote: My current understanding is that we intend to keep the web site on flac.sf.net and have a mirror on xiph.org/flac. I was thinking about it the other way around, but that was the default plan. On flac.sf.net, we probably don't have SSI, so that's a vote for a static site. I am however all in favor of whatever can be done to make updating and maintenance of the site easier. With the other Xiph websites we used SSI together with the svn:externals directive to automatically incorporate the latest version of shared resources in the live website. Git doesn't have an equivalent of svn:externals, so we're talking about having to run some script and push the output anyway. I agree the doxygen pages should be generated from the live (and release tag) versions of the code, not checked in. So some kind of generator, even if it's just a hacky script seems the way to go. I also don't see an easy way to automatically pull the sf.net website from the repository the way with do with xiph.org/flac. Sourceforge still has shell accounts, but apparently doesn't support cron, so I'll either have to set up a bot account to push updates, or just replace flac.sf.net with a redirect page. In the meantime, I've replaced the live version of flac.sf.net with the contents of the flac-website repo. I'll update that manually for now. If anyone can write patches, the highest priority bits are to add a news item about maintainership moving to xiph.org, and updating the developers page to point to the new git repository and this list. -r ___ 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
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
[flac-dev] Define 6.1 and 7.1 channel mappings
The FLAC format specification never defined the semantics of 7- and 8-channel files, which has caused some pain for some years now. Attached is a patch to define them. I don't know if this follows follows SMPTE/ITU-R recommendations, but it follows common tool practice. I chose the set of surround speaker designations used by home theatre systems, which is the same set used by the Vorbis and Opus mappings. The ordering follows the WAVE file format, rather than the Vorbis order of other Xiph codecs. This matches what flac has done for the existing mappings, and it allegedly what current tools like libavformat are doing. Please consider applying this patch to have a definitive statement on the channel map for implementors to follow. -r P.S. This doesn't update the flac command-line tool to enforce this mapping. That needs to be done as well, along with test files. From d3c3c44b26a2ed6c89a1051d33af962c87683c53 Mon Sep 17 00:00:00 2001 From: Ralph Giles gi...@xiph.org Date: Fri, 21 Sep 2012 14:12:09 -0700 Subject: [PATCH] Document a channel mapping for 7 and 8 channel audio. The FLAC spec hasn't previously documented channel definitions for 7 and 8 channel files, making it difficult to encode 6.1 an 7.1 audio. This makes that definition. The choice is based on popular surround configurations for home theatre and gaming, using the Microsoft WAVEX order, which most tools use internally. --- format.html | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/format.html b/format.html index 59ecd73..3cd8be2 100644 --- a/format.html +++ b/format.html @@ -1248,11 +1248,11 @@ li1 channel: mono/li li2 channels: left, right/li li3 channels: left, right, center/li - li4 channels: left, right, back left, back right/li - li5 channels: left, right, center, back/surround left, back/surround right/li - li6 channels: left, right, center, LFE, back/surround left, back/surround right/li - li7 channels: not defined/li - li8 channels: not defined/li + li4 channels: front left, front right, back left, back right/li + li5 channels: front left, front right, front center, back/surround left, back/surround right/li + li6 channels: front left, front right, front center, LFE, back/surround left, back/surround right/li + li7 channels: front left, front right, front center, LFE, back center, side left, side right/li + li8 channels: front left, front right, front center, LFE, back left, back right, side left, side right/li /ul /li li -- 1.7.9.6 (Apple Git-31.1) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Define 6.1 and 7.1 channel mappings
On Fri Sep 21 16:31:21 2012, Stephen F. Booth wrote: 6.1: L R C LFE Ls Rs Cs (MPEG 6.1 A layout) I'm confused. WAV puts the rear centre before everything but 'Front left of center' and 'Front right of center'. Are you saying you prefer the extra front channels to to side/rear surround, or that you prefer the MPEG order to the WAVE order? -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC From 32 Bits
On 12-06-02 6:14 PM, Chris wrote: Hello - I am new to the list and new to FLAC and I have an encoding question. I am using Goldwave to create a file which is 32 bits, signed, little endian. I am doing this to avoid the added step of converting from 16-bit samples to 32-bit samples. All works well except that encoding a sine wave does not output an exact replica of the sine wave -- far from it. When I encode a 16-bit sine wave and convert the 16-bit samples to 32 bits, all works well but the conversion process is time consuming. Changing the setting of FLAC__stream_encoder_set_bits_per_sample() doesn't solve the problem. I am using the stream encoder because eventually the output will go to a stream, but writing to a file for testing purposes. How do I encode to FLAC from native 32-bit files? Currently the reference encoder and decoders only support up to 24 bits per sample, according to http://flac.sourceforge.net/format.html#metadata_block_streaminfo So while the flac format does support 32-bit samples, it looks like you're out of luck for now. :-/ -r ___ 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
On 12-04-25 5:11 PM, Josh Coalson wrote: 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. Coverage of the test suite is something the test suite could be extended to measure. Encoder bugs can be very subtle and sometimes it takes someone with good knowledge of the format to notice. Sadly, this remains true anyway. It's best to have both automatic and human checks. Both are fallible. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Where is configure
On 9 April 2012 18:50, Danpoleary danpole...@netscape.net wrote: I downloaded the complete src from cvs. and as normal, I try to run ./configure, but it does not exist. All the documentation talks about it, but it is nowhere to be found. Also please be aware that there's newer development at https://git.xiph.org/?p=flac.git The CVS repository at sourceforge.net hasn't seen updates in some time. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Jenkins builds are failing
On 4 April 2012 04:54, Erik de Castro Lopo mle...@mega-nerd.com wrote: Can you please check out whats happening here? See: https://mf4.xiph.org/jenkins/job/flac/31/console There were some permission problems in the jenkins working tree; probably my fault. I cleaned up a bit and build #34 passed. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] uncompressed FLAC
On 8 March 2012 06:15, Martin Kos mar...@kos.li wrote: i have seen that the dbPowerAmp ripping and encoding software supports a new so-called FLAC uncompressed format I expect this is just encoding every block as 'SUBFRAME_VERBATIM'. I'm not aware of a switch on the normal flac encoder to do this, but it would be straightforward to add. This feature already exists in the format because there are occassional input blocks where the compression algorithm produces larger output than the input, so it's better just to store the equivalent data untransformed. File compression tools like gzip have a similar mode. I wouldn't worry about it though. It's unfortunate the dbPowerAmp developers want to take advantage of the subset of customer who don't understand what 'lossless' means. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Attention Ralph
On 25 February 2012 17:44, Erik de Castro Lopo mle...@mega-nerd.com wrote: Earl Chew forwared me an email he had submitted to this list but has never showed up. I've cleaned the spam trap. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Please test new endian stuff
On 5 February 2012 01:41, Erik de Castro Lopo mle...@mega-nerd.com wrote: a) On Linux, use the bswap_*() intrinsic. FWIW, Both Apple llvm-gcc 4.2.1 and Apple clang 3.0 support __builtin_bswap32() At least on XCode 4.2. It compiles to the bswap instruction. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Meet the new maintainer
On 4 February 2012 14:30, Erik de Castro Lopo mle...@mega-nerd.com 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. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Meet the new maintainer
On 1 February 2012 04:30, rapp...@dds.nl wrote: It's been a while since I've worked with Visual Studio, so some dumb questions ahead. To start: should I use http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express, or something else? That's a fine place to start if you have windows but don't already have a copy of the microsoft compiler. -r -- Ralph Giles Xiph.org Foundation for open multimedia ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Meet the new maintainer
On 1 February 2012 01:55, Erik de Castro Lopo mle...@mega-nerd.com wrote: Some time ago, I foolishly agreed to become the maintainer of FLAC, Thank you, Erik! Please find attached to patches which fix 'make dist' Unfortunately 'make distcheck' still fails, because test scripts don't work with out-of-tree builds. I have a partial fix for that, but I think it would be better to hoist most of the shell scripts into make and use the automake test support instead. The code has been moved to the Xiph.org git repo and I'll be trying to spend an hour a day on it until I get a backlog of patches reviewed, tweaked and applied. The main problem is that the FLAC test suite takes 30 minutes to run on a 2.8 GHz Core II Duo. I added a job to our jenkins continuous integration thing. Right now it doesn't test any more than you're proposing to do, but the results are public, which can be helpful. FWIW, -r 0001-Use-the-correct-project-filenames-for-flactimer.patch Description: Binary data 0002-Add-test_wrapper.sh-to-the-distribution.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Meet the new maintainer
On 1 February 2012 14:00, Ralph Giles gi...@thaumas.net wrote: I added a job to our jenkins continuous integration thing. Right now it doesn't test any more than you're proposing to do, but the results are public, which can be helpful. Er, which results are available at https://mf4.xiph.org/jenkins/job/flac/ Currently the build is failing on 'make distcheck' -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Support 56kHz to 19.2kHz gain analysis (Patch v3)
Sorry about the duplicate posts from Earl Chew. He's resent because the first v3 patch got caught in the moderation queue, and I didn't notice when I released the messages. Not his fault. :-) -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Support 56kHz to 19.2kHz gain analysis (Patch v3)
On 12 January 2012 16:07, Erik de Castro Lopo mle...@mega-nerd.com wrote: However, it looks like I'm changing jobs soon and should have two weeks free between finishing one and starting the other. Good thing you've got time off work so you can get work done! Shall I harass you about your patch queue at LCA? -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Support .cda as input files
On Fri, Sep 14, 2007 at 05:35:04PM -0400, Dan Pritts wrote: the format for CD-ROM sets aside space for error correction and therefore has less available for data. Red Book CD Audio still has error correction. Otherwise you'd *really* notice the scratches. On Fri, Sep 14, 2007 at 01:10:09AM +0200, Harry Sack wrote: does anybody know why dvd use files for audio and video but audio cd's not? What could be the reason for this? Otherwise, yes, as Dan said, The technology is almost 30 years old, and it's designed much more like a digital phonograph than a computer storage disk. CD-DA isn't even block addressable in the normal sense. The data is written in a continuous spiral from start to finish, with local signposts to help seeking. At the time, I expect there was no expectation of using it for data storage, and no need for the overhead of a conventional filesystem. Even DVD-Video only provides the filesystem structure as a convenience. IIRC it's possible to play a dvd by accessing the ifo files at a fixed offset and using the embedded sector references. -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] upcoming release, need help
On Fri, Sep 14, 2007 at 06:12:22PM -0700, Ralph Giles wrote: Do you know what features prompted the 1.7 automake version requirement? It seems to work fine with the 1.6.3 distributed by Apple. This was of course my suggestion originally. :P http://lists.xiph.org/pipermail/flac-dev/2006-November/002019.html I don't remember now if I just asked for 1.7 because that's what I had around to test or not. If you're brave, reduce it to 1.6 and see if anyone has problems. Should make the dist version compile out of the box (modulo asm) on MacOS X. -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Re: multiple core support
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? -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] Re: [Vorbis-dev] Re: Online Monthly Meeting scheduled to 11th July 2007, 06:00 UTC; Confirmed
On Wed, Jul 11, 2007 at 09:07:56PM +1000, Silvia Pfeiffer wrote: We will now have to prepare Internet-Drafts in preparation for new RFCs for the new mime types and get into a discussion with IETF/IANA as to changing the old registration. If that is not possible, we may need to revert to the earlier suggestion of keeping .ogg for anything in ogg rather than .ogx , and accept the problem that audio HW players are going to barf on .ogg video files. For what it's worth, I prefer this course in any case. So far, non-audio-non-video ogg files have been sufficiently scarce I don't think they warrant a separate .ogx extension. -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] Re: [Vorbis-dev] Proposal for Discussion: LICENSE and COPYRIGHT tags on Vorbis Comments
On Sun, Jul 08, 2007 at 02:03:05AM +0100, Ivo Emanuel Gonçalves wrote: Oh, really? Well, be kind enough to provide me a link. I'll be deleting the wiki page and try to add the information somewhere else more relevant. Sorry, I should have before. http://xiph.org/vorbis/doc/v-comment.html -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] Re: [Vorbis-dev] Proposal for Discussion: LICENSE and COPYRIGHT tags on Vorbis Comments
On Sun, Jul 08, 2007 at 01:13:40AM +0100, Ivo Emanuel Gonçalves wrote: This proposal states two new tags, LICENSE and COPYRIGHT. These are not new tags. They have been part of the recommended interoperability set for years, and are the standard way of flagging such information in ogg files. Hopefully you can find your chat partner and let them know! The LICENSE tag must store an URI pointing to the relevant license documentation. The current recommendation is more general. Maybe we should amend it to suggest including a URL for machinability. The COPYRIGHT tag must store the name of the authoring person or entity. A date should not be stored here, as a DATE tag already exists. Example: COPYRIGHT=Xiph.Org Foundation A full statement is also acceptable: COPYRIGHT=Copyright (C) 2007 Your Records, Ltd. All rights reserved. I would like to hear from those who agree and disagree with this proposal. I think it's a good idea. Tool support could be better though. :) -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] newbie questions
On Sat, Dec 23, 2006 at 05:59:59PM -0600, Mike M wrote: 2nd: I've been looking for specs on flac metadata standards for tag info [...] MediaMonkey is writing the tags similiarly to the ogg/vorbis standard, That's correct. FLAC uses the same tag set (and format, roughly) as the the vorbis set. The official set is documented here: http://xiph.org/vorbis/doc/v-comment.html if those don't do it for you (it's enough for pop, not classical) there are some more complete collections: http://reactor-core.ogg/ogg-tagging.html http://www.ghophernet.org/articles/vorbiscomment/ (for example) HTH, -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [PATCH] Re: [Flac-dev] Strangeness with OggFlac files
On Tue, Nov 07, 2006 at 06:31:04AM +1100, Erik de Castro Lopo wrote: I haven't tested it, but I don't think just setting packet.e_o_s is sufficient to close the stream. The forced ogg_stream_flush() is required. libogg checks the e_o_s flag (and has always done so, according to svn) so you shouldn't have to call ogg_stream_flush() except when you want to force a page boundary (such as after the header packets). ogg/src/framing.c line 449 One common mistake it to not loop on ogg_stream_pageout() but it looks like ogg_encoder_aspect.c is doing that. -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Metadata RDF
On Sun, Oct 01, 2006 at 01:17:32PM +0200, Danny Ayers wrote: Not always - the following is valid (though rather unusual!) RDF/XML : html xmlns=http://www.w3.org/1999/xhtml; body pblockquoteMixup/blockquote/p /body /html I wonder if that's a bug, since there's not actually any RDF there, and this would detect as xhtml by a reader. Yep. Hmm, if there was a neat way to provide the media (mime) type it could also be useful for non-XML docs as well. Otherwise an easy workaround for RDF might be to specify that the root element for RDF docs must be rdf:RDF xmlns=http://www.w3.org/1999/02/22-rdf-syntax-ns#; / (as was the case in the pre-2004 RDF specs). Seems reasonable for this application. I guess I've not read the more recent specs. Isn't there a connotation of the RDF describing the xml document it's embedded in if it's not the root element? -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Metadata RDF
On Sat, Sep 30, 2006 at 12:21:53PM +0200, Danny Ayers wrote: Basically I'd like to embed arbitrary (meta)data in flac files. I agree it would be best to define a new block type for RDF metadata, or probably better for random attached XML data, and let the xml parser figure out what schema it's using. It's easy to recognize RDF-in-XML but retains flexibility for people to add other XML encoded metadata in the future. IMHO, -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] Google Summer of Code with Xiph.org
All, I'm pleased to announce that Xiph.org has been selected as a mentoring organization for the 2006 Google Summer of Code program. So if you need a summer job, and there's something about free multimedia that's been bugging you, here's your chance! We've put up some project ideas for things we'd like to see in the wiki http://wiki.xiph.org/index.php/Summer_of_Code But of course you're welcome to submit proposals for original or modified projects as well. Feel free to discuss ideas here on the public lists, or privately with the listed mentors before submitting officially. Google is now taking applications. You can apply by signing in here: http://code.google.com/soc/ With your google account info. If you don't already have one you can register a new account (including using an external, non-gmail address) here: https://www.google.com/accounts/NewAccount You'll need cookies and such. You submit a proposal, our mentors will rank them, and then google will decide what to fund. See the drupal project's http://drupal.org/node/59037 and http://drupal.org/node/59963 for some excellent advice on preparing your application. More information and a complete list of mentoring organizations is available at http://code.google.com/soc/ We're looking forward to having some funded projects this summer, so good luck! -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] intel macs
On Wed, Jan 18, 2006 at 08:34:33AM -0500, Scott C. Brown 02 wrote: does anything special need to be done to get flac working on the intel macs? I've not heard a positive build report, but I don't expect there to be any issues. -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
On Mon, Jan 24, 2005 at 05:43:04PM -0800, Josh Coalson wrote: because of the mess and since there have been API changes and additions in both libFLAC and libOggFLAC since 1.1.1 I plan on bumping all the libtool numbers as follows: current++, revision=0 age=0. if this will cause problems please let me know. That should resolve the issues. Thanks. -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
On Sat, Jan 08, 2005 at 08:31:47PM -0800, Matt Zimmerman wrote: liboggflac1 did not change the soname (better check this, it might require a soname change, check the seekable ogg-flac support stuff). CCing upstream on this. Josh, did 1.1.1 change interfaces in liboggflac? If so, it needs a soname change. Most of the changes were compatible, but it looks like some of the OggFLAC__StreamDecoderState enum entries changed position, so the soname should increment. Also, note that the file format changed to fix the streaming issues. liboggflac* prior to 1.1.1 is deprecated and debian should not support it. -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] Monthly Meeting January 5 at 1200 GMT
Hi all, Just posting a reminder that the next Xiph.org organizational Monthly Meeting is scheduled for next week, 2005 January 5 at 12:00 GMT. We'll be alternating the 1200 time with our usual 2400 time this year to make it easier for folks in Europe to attend. The Monthly Meetings are held on irc, and help to keep everyone involved/interested in xiph work appraised of each other's progress. Keep us all pulling in the same general direction if you will. The meetings usually last about an hour. So please join #xiphmeet on irc.freenode.net when the date comes if you're available. You can add to the agenda in the wiki at http://wiki.xiph.org/index.php/MonthlyMeeting200501 Hope you can make it, -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Legal sample rates
On Tue, Nov 16, 2004 at 09:30:09AM -0800, Josh Coalson wrote: PS: I seem to be having a great deal of trouble with the xiph.org mail server. It seems to be silently deleting some of my emails. I sometimes need to resend my emails 2 or 3 times before it gets through to the list. Just as an aside, we did have some trouble last week; our mail server changed IP addresses, and while we have an MX redirect installed, it apparently didn't get updated promptly. Why this resulted in undeliverable bounces rather than late delivery I don't know. If you're still having trouble this week, let us know in case there's something else wrong. I'll go clean the mod queue, so we'll see if that's the problem. Usually things are just held if they're sent from an unsubscribed address. We have some auto-discard filters as well (thank god) but they're unlikely to cull a message one time and let it through another. Please accept my appologies on the behalf of my fellow humans for ruining email. :P -r ___ Flac-dev mailing list [EMAIL PROTECTED] http://lists.xiph.org/mailman/listinfo/flac-dev
