Re: [flac-dev] [Flac-dev] mid-side coding and bits per sample
the side channel bps is 1 larger than the raw bps because it's a difference
between left and right channel values.
From: Eri Eri gugui...@hotmail.com
To: flac-dev@xiph.org
Sent: Monday, September 26, 2011 1:17 AM
Subject: [Flac-dev] mid-side coding and bits per sample
Dear list,
i'm doing a bit of analisys on flac's source code and i've run into something
i can't quite grasp.
flac version 1.2.1
flaclib C
stream_encoder.c
function process_subframes_
line 2999
++
if(do_mid_side) {
FLAC__ASSERT(encoder-protected_-channels == 2);
for(channel = 0; channel 2; channel++) {
const unsigned w =
get_wasted_bits_(encoder-private_-integer_signal_mid_side[channel],
encoder-protected_-blocksize);
encoder-private_-subframe_workspace_mid_side[channel][0].wasted_bits =
encoder-private_-subframe_workspace_mid_side[channel][1].wasted_bits = w;
encoder-private_-subframe_bps_mid_side[channel] =
encoder-protected_-bits_per_sample - w + (channel==0? 0:1);
}
}
In that piece of code the encoder determines how many wasted bits there are in
each channel (mid-side) and calculates effective BPS for each of them. What i
don't understand is why it should add one bit to the BPS of the side channel
(channel==0? 0:1), eventhough there is no correction to wasted bits. Could
someone shed light on this?
Thank you very much in advance!
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to completion
I haven't checked git yet but I hope this patch has not gone in. I don't like the special case that this is creating. It would be better to allow MM:SS everywhere but I consider that low priority. From: Earl Chew earl_c...@yahoo.com To: flac-dev@xiph.org flac-dev@xiph.org Sent: Thursday, January 5, 2012 8:27 PM Subject: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to completion When reading the INDEX from the cue sheet, the format MM:SS:FF format is disallowed if the sample frequency is not a multiple of 75 because the index would only be approximate. However, 00:00:00 is _exact_ because it denotes the start of the track, so allow it as a special case. This allows metaflac_test.sh to pass. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Meet the new maintainer
I'll throw this thought out here so it doesn't get lost: when it came time for me to build a Windows release, I always used a quarantined Windows box that had the minimum stuff installed and had never been on a network, to avoid malware getting into the binaries. The last thing I ever wanted to hear was some Windows user blaming FLAC because a bad build infected him. It was bad enough when some AV software was misidentifying a release as infected; it took months after the virus defs were updated for that stink to wear off. From: Erik de Castro Lopo mle...@mega-nerd.com To: flac-dev@xiph.org Sent: Saturday, February 4, 2012 9:16 PM Subject: Re: [flac-dev] Meet the new maintainer Ralph Giles wrote: On 4 February 2012 14:30, Erik de Castro Lopo 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. Would be very cool if you could set that up. Having Jenkins test on the platform that I do all of my hacking on is not all that useful. Having Jenkins test on Windows and OS X would be *really* useful. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Meet the new maintainer
No, this has been addressed before. The FLAC format has no compression levels or even any encoding parameters that cannot be gleaned from the frame headers. Everything else is implementation-specific and doesn't need official metadata support for. From: Olav Sunde o...@olavsunde.net To: flac-dev@xiph.org Sent: Monday, February 6, 2012 3:16 AM Subject: Re: [flac-dev] Meet the new maintainer At 09:33 02.02.2012, you wrote: Thanks Erik, I'll check back. This next is a feature request: Today it is not possible to know the encoding of a flac archive. Many new devices support playback of flac, however tiny processors sometimes have a hard time decoding files with the default encoding of -5 or higher, resulting in unstable playback or even reduced audio quality. A re-encoding to -0 often solve these issues. Can you look at a way to store parameters used for encoding in an archive so we can check it later? Best regards Olav Sunde Olav Sunde wrote: very good to see activity on flac development again. I am not a developer unfortunately, but I'd like to check with you if updating code for flac/metaflac to handle high-rez files (24/192 or higher) for writing Replay Gain tags is in your 'pile' of things to fix? I think there are patches to do that in the queue. Perhaps you can check back in two weeks or so. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to completion
Josh Coalson wrote: I haven't checked git yet but I hope this patch has not gone in. I don't like the special case that this is creating. It would be better to allow MM:SS everywhere but I consider that low priority. I modified version of that patch did go in. See the following commits: https://git.xiph.org/?p=flac.git;a=commit;h=19050f74eaa1aa6d609ca065e1a854ada5bb6b4c https://git.xiph.org/?p=flac.git;a=commit;h=7ee908403e8be011b8a7dd3bf511408b40312c2e https://git.xiph.org/?p=flac.git;a=commit;h=ce8a75134cace056f6c436d54b57bad1a1d93797 Erik -- -- 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-dev] Git branch with compiling fixes for win32
Josh Coalson wrote: But regardless of submitter, any patch that affects encoding must be reviewed very carefully, preferably by several other people and definitely me. Is there any way of encoding this manual review process in the test suite so that people hacking on FLAC can immediately see that soemthing is wrong before even attempting to submit a patch (assuming they run the test suite)? Erik -- -- 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-dev] Git branch with compiling fixes for win32
From: Erik de Castro Lopo mle...@mega-nerd.com To: flac-dev@xiph.org Cc: Josh Coalson xf...@yahoo.com Sent: Wednesday, April 25, 2012 4:42 PM Subject: Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32 Josh Coalson wrote: But regardless of submitter, any patch that affects encoding must be reviewed very carefully, preferably by several other people and definitely me. Is there any way of encoding this manual review process in the test suite so that people hacking on FLAC can immediately see that soemthing is wrong before even attempting to submit a patch (assuming they run the test suite)? Erik Part of the reason the current test suite is so long is to try and discover those problems automatically. But it's not possible to be exhaustive simply because new code may not be covered by the test suite. Encoder bugs can be very subtle and sometimes it takes someone with good knowledge of the format to notice. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to completion
From: Erik de Castro Lopo mle...@mega-nerd.com To: flac-dev@xiph.org Cc: Josh Coalson xf...@yahoo.com Sent: Wednesday, April 25, 2012 4:30 PM Subject: Re: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to completion Josh Coalson wrote: I haven't checked git yet but I hope this patch has not gone in. I don't like the special case that this is creating. It would be better to allow MM:SS everywhere but I consider that low priority. I modified version of that patch did go in. See the following commits: https://git.xiph.org/?p=flac.git;a=commit;h=19050f74eaa1aa6d609ca065e1a854ada5bb6b4c https://git.xiph.org/?p=flac.git;a=commit;h=7ee908403e8be011b8a7dd3bf511408b40312c2e https://git.xiph.org/?p=flac.git;a=commit;h=ce8a75134cace056f6c436d54b57bad1a1d93797 Erik I saw. I like almost all the progress on recent patches but not this one. Can it be backed out or replaced with proper MM:SS handling? ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] pkg-config output and FLAC/assert.h
From: Paul Davis p...@linuxaudiosystems.com
To: flac-dev@xiph.org
Cc:
Sent: Friday, March 25, 2011 5:39 AM
Subject: Re: [Flac-dev] pkg-config output and FLAC/assert.h
On Fri, Mar 25, 2011 at 5:32 AM, Erik de Castro Lopo
mle...@mega-nerd.com wrote:
Hi,
FLAC helpfully provides a flac.pc file. Unfortunately there is a
nasty interaction between that file and system header files.
If ones installs flac and relies on pkg-config to find the CFLAGS
one woulf get CFLAGS value of -I${includedir}/FLAC which
suggests
that FLAC header files like metadata.h should be included as:
#include metadata.h
However, FLAC also ships an assert.h header file. If one writes
code that wants needs both the Standard C assert.h and the FLAC
header files, we run into a problem, the C compiler finds FLAC's
assert.h instead of the Standard C version.
I believe the correct solution to this problem is the change the
Cflag value in flac.pc to -I${includedir} and then encourage
people to use:
#include FLAC/metadata.h
#include FLAC/assert.h
#include assert.h
which will no longer conflict.
Opinions?
i recall raising this as an issue about 18 months ago. i certainly
feel that the include style that flac uses now is simply wrong, and
that your suggestion above (which matches the one i made) is
substantially preferable.
I didn't follow, which style is wrong? I never liked lazy search paths like:
-I.../include/FLAC
#include metadata.h
because of the potential for conflict with other headers. The code
should be using this style everywhere:
-I.../include
#include FLAC/metadata.h
Then there is no problem with
#include FLAC/assert.h
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] pkg-config output and FLAC/assert.h
Josh Coalson wrote:
From: Paul Davis p...@linuxaudiosystems.com
To: flac-dev@xiph.org
Cc:
Sent: Friday, March 25, 2011 5:39 AM
Subject: Re: [Flac-dev] pkg-config output and FLAC/assert.h
On Fri, Mar 25, 2011 at 5:32 AM, Erik de Castro Lopo
mle...@mega-nerd.com wrote:
Hi,
FLAC helpfully provides a flac.pc file. Unfortunately there is a
nasty interaction between that file and system header files.
If ones installs flac and relies on pkg-config to find the CFLAGS
one woulf get CFLAGS value of -I${includedir}/FLAC which
suggests
that FLAC header files like metadata.h should be included as:
#include metadata.h
However, FLAC also ships an assert.h header file. If one writes
code that wants needs both the Standard C assert.h and the FLAC
header files, we run into a problem, the C compiler finds FLAC's
assert.h instead of the Standard C version.
I believe the correct solution to this problem is the change the
Cflag value in flac.pc to -I${includedir} and then encourage
people to use:
#include FLAC/metadata.h
#include FLAC/assert.h
#include assert.h
which will no longer conflict.
Opinions?
i recall raising this as an issue about 18 months ago. i certainly
feel that the include style that flac uses now is simply wrong, and
that your suggestion above (which matches the one i made) is
substantially preferable.
I didn't follow, which style is wrong? I never liked lazy search paths like:
-I.../include/FLAC
#include metadata.h
because of the potential for conflict with other headers. The code
should be using this style everywhere:
-I.../include
#include FLAC/metadata.h
Then there is no problem with
#include FLAC/assert.h
Correct.
The problem is that currently the pkg-config shipped with most distros
(ie from the last release) gives this:
$ pkg-config --cflags flac
-I/usr/include/FLAC
This encourages people in client code to do:
#include all.h
which obviously has the potential to cause problems.
Instead pkg-config should give:
$ pkg-config --cflags flac
-I/usr/include/FLAC
so that client code can do:
#include FLAC/all.h
I'll submit a patch to fix this.
Cheers,
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
Josh Coalson wrote: From: Erik de Castro Lopo mle...@mega-nerd.com To: flac-dev@xiph.org Cc: Josh Coalson xf...@yahoo.com Sent: Wednesday, April 25, 2012 4:42 PM Subject: Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32 Josh Coalson wrote: But regardless of submitter, any patch that affects encoding must be reviewed very carefully, preferably by several other people and definitely me. Is there any way of encoding this manual review process in the test suite so that people hacking on FLAC can immediately see that soemthing is wrong before even attempting to submit a patch (assuming they run the test suite)? Erik Part of the reason the current test suite is so long is to try and discover those problems automatically. But it's not possible to be exhaustive simply because new code may not be covered by the test suite. Encoder bugs can be very subtle and sometimes it takes someone with good knowledge of the format to notice. What exactly is the problem? New versions of the encoder producing files that can't be decoded by older decoders or something else? 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] Fix cuesheet.c to allow metaflac_test.sh to run to completion
Josh Coalson wrote: From: Erik de Castro Lopo mle...@mega-nerd.com To: flac-dev@xiph.org Cc: Josh Coalson xf...@yahoo.com Sent: Wednesday, April 25, 2012 4:30 PM Subject: Re: [flac-dev] Fix cuesheet.c to allow metaflac_test.sh to run to completion Josh Coalson wrote: I haven't checked git yet but I hope this patch has not gone in. I don't like the special case that this is creating. It would be better to allow MM:SS everywhere but I consider that low priority. I modified version of that patch did go in. See the following commits: https://git.xiph.org/?p=flac.git;a=commit;h=19050f74eaa1aa6d609ca065e1a854ada5bb6b4c https://git.xiph.org/?p=flac.git;a=commit;h=7ee908403e8be011b8a7dd3bf511408b40312c2e https://git.xiph.org/?p=flac.git;a=commit;h=ce8a75134cace056f6c436d54b57bad1a1d93797 Erik I saw. I like almost all the progress on recent patches but not this one. Can it be backed out or replaced with proper MM:SS handling? I really like the idea of fixing it with proper MM:SS handling. 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-dev] pkg-config output and FLAC/assert.h
Erik de Castro Lopo wrote: The problem is that currently the pkg-config shipped with most distros (ie from the last release) gives this: $ pkg-config --cflags flac -I/usr/include/FLAC This encourages people in client code to do: #include all.h which obviously has the potential to cause problems. Instead pkg-config should give: $ pkg-config --cflags flac -I/usr/include/FLAC so that client code can do: #include FLAC/all.h I'll submit a patch to fix this. Actually, thats already been fixed in Git: commit 7ae181f27c16e7eca45840ec9171b938b9f86fbc Author: Josh Coalson jcoal...@users.sourceforce.net Date: Sat Nov 29 20:56:09 2008 + remove /FLAC++ suffix on include path commit b76d4f817c54c6fcfcb82fe72e38660c1b480774 Author: Josh Coalson jcoal...@users.sourceforce.net Date: Sat Nov 29 20:55:52 2008 + remove /FLAC suffix on include path 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
