On Jan 1, 2013, at 13:02, Ralph Giles wrote:
> 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
> befo
Martijn van Beurden wrote:
> Hi guys,
>
> While updating the FLAC website I just found out the Xiph directshow
> filters already implement a certain channel mapping. I found this bug:
> https://trac.xiph.org/ticket/1657 It seems, from the bug report, that
> they use FL, FR, FC, LFE, BL, BR, SL
Hi guys,
While updating the FLAC website I just found out the Xiph directshow
filters already implement a certain channel mapping. I found this bug:
https://trac.xiph.org/ticket/1657 It seems, from the bug report, that
they use FL, FR, FC, LFE, BL, BR, SL, SR.
On 22-01-13 08:19, Brian Willough
On Jan 17, 2013, at 21:41, Ralph Giles wrote:
> 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?
Professional surround mastering is delivered on very specific medi
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/mail
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
I vote for documenting the --channel-map option in the --help
I don't like the idea of rejecting a multichannel file merely for
mapping, so there should be a documented option plus an error message
pointing to the option. This should compare to the WAVE and AIFF
errors where the utility sugg
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
"Stephen F. Booth" wrote:
...
> http://msdn.microsoft.com/en-us/library/windows/hardware/gg463006.aspx
> hasn't been updated since 2007 so I may have been looking at an old
> document.
The document you cite is the Mircosoft
standard; its usual URL is:
http://msdn.microsoft.com/en-us/windows/hardwa
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
Tim's proposal seems reasonable but it conflicts with the FLAC documentation
that says the channel ordering follows SMPTE/ITU-R recommendations. I think we
may be butting up against an area where the standards aren't clear. ITU-R
BS.2159-4
(http://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BS.21
Tim W. wrote:
> I'm personally in favor of mapping (1) as it doesn't vary between 6.1/7.1,
> and is fully compatible with the WAVEFORMATEXTENSIBLE specification.
I'm in favour of Tims proposal and intent to apply Ralph's patch
to implement this unless someone comes up with a really good reason
no
I apologize for the terribly long message, but here goes.
-
First, regarding existing tools that I now about.
libavcodec and users (e.g. HandBrake):
- if there are 6 channels or less, the layout is s
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 resear
Ralph Giles wrote:
> 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
> pra
On Sunday, September 23, 2012 at 2:04 PM, Ralph Giles wrote:
> 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 should have been clearer with the labels I was using:
L = Left
R = Right
C = Center
LFE = Low frequency effects
Ls = Left surroun
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)
Having read a bit more:
This matches the WAV (or USB) order if you map Ls (Left Surround?) to
Back Left and Rs (Right surround) to Back Right, instead of mapping them
to Side Left and Side Right a
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 th
I like the idea of standardizing the channel maps. I would suggest the
following channel orderings:
6.1: L R C LFE Ls Rs Cs (MPEG 6.1 A layout)
7.1: L R C LFE Ls Rs Rls Rrs (MPEG 7.1 B layout)
I think this more closely matches what Apple has done and what the default WAVE
channel order is
On 09/21/2012 05:22 PM, Ralph Giles wrote:
> 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 fo
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 surrou
21 matches
Mail list logo
