30 Nov
2009
30 Nov
'09
5:11 p.m.
Hi
A friend of mine has invited me to compose for some videos he's planning
on making. We haven't started yet, but I thought it might be good to be
a bit ahead, especially since I haven't done this before and I know next
to nothing about video...
The noise making apps will be running ontop of jack. Google suggest I
should look into xjadeo with the -i switch. Is that it? Anything
(formats, codecs, framerates, interlaces other-stuff-I-dont-get) that I
should ask for or try to avoid?
Any input, including links, tips, thoughts, would be highly appreciated!
--
Atte
http://atte.dk http://modlys.dk
30 Nov
30 Nov
5:39 p.m.
On Mon, Nov 30, 2009 at 4:11 PM, Atte André Jensen
<atte.jensen(a)gmail.com> wrote:
Hi
A friend of mine has invited me to compose for some videos he's planning
on making. We haven't started yet, but I thought it might be good to be
a bit ahead, especially since I haven't done this before and I know next
to nothing about video...
The noise making apps will be running ontop of jack. Google suggest I
should look into xjadeo with the -i switch. Is that it? Anything
(formats, codecs, framerates, interlaces other-stuff-I-dont-get) that I
should ask for or try to avoid?
do you enjoy being whipped repeatedly by leather 9-tailed whips spiked
with stainless steel blades? no, i thought not. well, sign up for
that, because its going to be more enjoyable than the video thing.
possibly even a *lot* more enjoyable.
7:15 p.m.
Paul Davis wrote:
do you enjoy being whipped repeatedly by leather
9-tailed whips spiked
with stainless steel blades? no, i thought not. well, sign up for
that, because its going to be more enjoyable than the video thing.
possibly even a *lot* more enjoyable.
Uhmmm, sounds promising :-)
Exactly what do you mean with "the video thing"? The process I'm trying
to start (composing for film), the technical aspects/problems of it or
the video-container-codecs-and-friends-jungle?
--
Atte
http://atte.dk http://modlys.dk
1 Dec
1 Dec
11:57 a.m.
On Mon, Nov 30, 2009 at 6:15 PM, Atte André Jensen
<atte.jensen(a)gmail.com> wrote:
Paul Davis wrote:
mostly the latter.
i thought the audio tech world was a mess, what with different cable
interconnects, sample rates, sample formats, audio file formats,
plugin formats etc. etc. etc.
my brief and very superficial experience with the video tech world
suggests that its at least twice as bad, perhaps 100x as bad.
do you enjoy being whipped repeatedly by leather
9-tailed whips spiked
with stainless steel blades? no, i thought not. well, sign up for
that, because its going to be more enjoyable than the video thing.
possibly even a *lot* more enjoyable.
Uhmmm, sounds promising :-)
Exactly what do you mean with "the video thing"? The process I'm trying to
start (composing for film), the technical aspects/problems of it or the
video-container-codecs-and-friends-jungle? 
6:23 p.m.
Paul Davis <paul(a)linuxaudiosystems.com> writes:
my brief and very superficial experience with the
video tech world
suggests that its at least twice as bad, perhaps 100x as bad.
Right, but we can avoid much of this with stuff like JACK-VIDEO, if it's
done as simple as JACK-AUDIO, using RGBA32 RAW video. For
encoding/decoding and such, there are plenty of other tools.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
sip:b0ef@ e e
jid:b0ef@ n n
6:31 p.m.
Esben Stien wrote:
Paul Davis <paul(a)linuxaudiosystems.com> writes:
Why RGBA32 RAW? Who in the professional video world would use such a format?
Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net
my brief and very superficial experience with the
video tech world
suggests that its at least twice as bad, perhaps 100x as bad.
Right, but we can
avoid much of this with stuff like JACK-VIDEO, if it's
done as simple as JACK-AUDIO, using RGBA32 RAW video. For
encoding/decoding and such, there are plenty of other tools.
6:56 p.m.
Florian Faber <faber(a)faberman.de> writes:
Why RGBA32 RAW?
Not sure what you mean. This would just be a RAW image data
sequence. Like RAW PCM 24 bit samples for audio.
Who in the professional video world would use such a
format?
What else would you use?.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
sip:b0ef@ e e
jid:b0ef@ n n
7:41 p.m.
Esben Stien wrote:
Something that wouldn't cripple my data, if my input data has 12bpp. I
don't think you can solve this problem by just using one pixel format.
RGB with floats could be one possible solution, but one 4K frame would
be 99MB.
Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net
Florian Faber <faber(a)faberman.de> writes:
Well, and for the same reason jack doesn't use 24bit PCM as native
format, this is a not a good idea for video data.
Why RGBA32 RAW?
Not sure what you mean.
This would just be a RAW image data
sequence. Like RAW PCM 24 bit samples for audio. Who in the
professional video world would use such a format?
What else would you use?.
7:55 p.m.
Florian Faber <faber(a)faberman.de> writes:
Well, and for the same reason jack doesn't use
24bit PCM as native
format, this is a not a good idea for video data.
I'm sorry. I do not understand what you mean. You don't want to transfer
RGB with JACK-VIDEO. I find that that's the beauty and simplicity of it
all.
Something that wouldn't cripple my data, if my
input data has 12bpp.
Alright, so you mean here that you want to transfer 12bpp. Well, of
course, that's doable. The point being that we transfer RGB data, not
something else.
I don't think you can solve this problem by just
using one pixel
format.
If we don't, we start to complicate things. The point of simplicity I
was thinking of was just starting JACK-VIDEO with a single RGB pixel
format (12bpp doable).
RGB with floats could be one possible solution, but
one 4K frame would
be 99MB.
Right, but I don't think bandwidth will be a problem by the time we
actually get JACK-VIDEO running with good applications.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
sip:b0ef@ e e
jid:b0ef@ n n
9:02 p.m.
You would be suprised. RGBA32 is used quite commonly in the compositor
world, usually stored as a sequence of images, with even higher precisions
available. Raw RGB24 is reasonably common with the video professionals I
know, when I questioned them about it they said that they could acheive more
film like colour grading than they could in any of the YUV colour spaces.
It's probably not the best format for realtime work given the amount of data
that needs to be transmitted (or maybe it is), I have previously worked with
piping raw YUV (yuv4linux) between applications and having something like
jack to manage the connections would be a godsend.
Why RGBA32 RAW? Who in the professional video world
would use such a
format?
Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
9:33 p.m.
On Tue, Dec 1, 2009 at 8:02 PM, Danni Coy <danni.coy(a)gmail.com> wrote:
You would be suprised. RGBA32 is used quite commonly
in the compositor
world, usually stored as a sequence of images, with even higher precisions
available. Raw RGB24 is reasonably common with the video professionals I
know, when I questioned them about it they said that they could acheive more
film like colour grading than they could in any of the YUV colour spaces.
It's probably not the best format for realtime work given the amount of data
that needs to be transmitted (or maybe it is), I have previously worked with
piping raw YUV (yuv4linux) between applications and having something like
jack to manage the connections would be a godsend.
my understanding is that one of the many problems that video faces is
that there truly is no equivalent to "32 bit floating point for
audio". whereas this format for audio samples is pretty much
acceptable for just about all purposes, and the ones not satisfied by
it are corner cases, in video there are many common cases that prefer
quite different data representations. for an audio analogy, imagine a
JACK world where some clients wanted FFT-bin data while others wanted
floating point encoding of PCM.
until or unless someone can step up and authoritatively say "the
interchange format for video is XXXXXX", its hard to imagine a "jack
for video" system really working very usefully for a significant
number of people. those who work entirely in the RGBA32 or YUV spaces
would be happy with just that format; anyone mixing processing that is
better suited to different formats is going to take a hell of a
performance hit.
--p
10:27 p.m.
On 12/02/2009 12:33 PM, Paul Davis wrote:
On Tue, Dec 1, 2009 at 8:02 PM, Danni
Coy<danni.coy(a)gmail.com> wrote:
Anyone who has those extreme requirements can probably afford to buy the
hardware required to run the system.
2 playstation3 boxes would probably provide enough grunt to manage the
load for converting on the fly between the formats.
Patrick Shirkey
Boost Hardware Ltd
You would be suprised. RGBA32 is used quite
commonly in the compositor
world, usually stored as a sequence of images, with even higher precisions
available. Raw RGB24 is reasonably common with the video professionals I
know, when I questioned them about it they said that they could acheive more
film like colour grading than they could in any of the YUV colour spaces.
It's probably not the best format for realtime work given the amount of data
that needs to be transmitted (or maybe it is), I have previously worked with
piping raw YUV (yuv4linux) between applications and having something like
jack to manage the connections would be a godsend.
my understanding is that one of the many problems that video faces is
that there truly is no equivalent to "32 bit floating point for
audio". whereas this format for audio samples is pretty much
acceptable for just about all purposes, and the ones not satisfied by
it are corner cases, in video there are many common cases that prefer
quite different data representations. for an audio analogy, imagine a
JACK world where some clients wanted FFT-bin data while others wanted
floating point encoding of PCM.
until or unless someone can step up and authoritatively say "the
interchange format for video is XXXXXX", its hard to imagine a "jack
for video" system really working very usefully for a significant
number of people. those who work entirely in the RGBA32 or YUV spaces
would be happy with just that format; anyone mixing processing that is
better suited to different formats is going to take a hell of a
performance hit.
2 Dec
2 Dec
12:46 a.m.
This seems to be due to the massive amounts of IO needed for realtime video
When I was working with YUV4Linux (basically a DVD stream without encryption
or compression) for a 2 GB file I was getting 2 minutes and 18 seconds at
PAL DV resolution. Raw rgb should be almost double that and rgba more than
double. HD resolutions will double and quadruple the amount of
memory/storage needed.
To get data between applications I was using Fifos. Which work, but are
difficult to set up and tempremental at the best of times.
I don't think it would be that realistic to work with compression between
applications in jack type situation. though colour space compression should
be possible
to give some idea of the memory/disk IO requirements needed.
I did some quick calculations
comparing a pal dv sized stream 720 x 576 @ 25 frames a second
vs 48 000 samples per second floating point audio stream.
rgba 32bit float = 864 48k audio streams.
rgba 8bit int = 216 48k audio streams.
rgb 8 bit int = 162 48k audio streams
YCrCb 422 = 108 48k audio streams
YCrCb 420 = 81 48k audio streams
for 720p
rgb 8bit = 360 48k audio streams
YCrCb 420 = 180 " " "
for 1080p
rgb 8bit = 810 48k audio streams
Are there any other color spaces I should be worried about?
Most compositors use RGBA internally either as 8bit int or floats.
FreiOr is a set of video plugins used by a lot of different video editing
programs it prefers rgba 8888, (bgra8888 is the other option) so that format
must at least be acceptable to a lot of video editors. Effectv is the other
shared video plugin set I am aware of and it uses rgb888.
Cinelerra supports RGBA float, RGBA 8888 & YUVA 8888 and non Alpha varients
of the above.
Perhaps the most sensible Idea would be to concider purhaps RGB(A) 888(8)
and YUV(A) 888(8) as different types of port.
On Wed, Dec 2, 2009 at 11:33 AM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
On Tue, Dec 1, 2009 at 8:02 PM, Danni Coy
<danni.coy(a)gmail.com> wrote:
You would be suprised. RGBA32 is used quite
commonly in the compositor
world, usually stored as a sequence of images, with even higher
precisions
available. Raw RGB24 is reasonably common with
the video professionals I
know, when I questioned them about it they said that they could acheive
more
film like colour grading than they could in any
of the YUV colour spaces.
It's probably not the best format for realtime work given the amount of
data
that needs to be transmitted (or maybe it is), I
have previously worked
with
piping raw YUV (yuv4linux) between applications
and having something like
jack to manage the connections would be a godsend.
my understanding is that one of the many problems that video faces is
that there truly is no equivalent to "32 bit floating point for
audio". whereas this format for audio samples is pretty much
acceptable for just about all purposes, and the ones not satisfied by
it are corner cases, in video there are many common cases that prefer
quite different data representations. for an audio analogy, imagine a
JACK world where some clients wanted FFT-bin data while others wanted
floating point encoding of PCM.
until or unless someone can step up and authoritatively say "the
interchange format for video is XXXXXX", its hard to imagine a "jack
for video" system really working very usefully for a significant
number of people. those who work entirely in the RGBA32 or YUV spaces
would be happy with just that format; anyone mixing processing that is
better suited to different formats is going to take a hell of a
performance hit.
--p
3 Dec
3 Dec
8:57 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul Davis schrieb:
...
On Mon, Nov 30, 2009 at 6:15 PM, Atte André Jensen
<atte.jensen(a)gmail.com> wrote:
...
Exactly what
do you mean with "the video thing"? The process I'm trying to
start (composing for film), the technical aspects/problems of it or the
video-container-codecs-and-friends-jungle?
mostly the latter. my brief and very superficial experience with the
video tech world
suggests that its at least twice as bad, perhaps 100x as bad.
Of course it is. Happily, we as the musicians can sit back and enjoy
watching the video-people being flogged - and flogging themselfs.
As long as one can arrange an agreement with the video-makers, that
generic 48/16 BC-Wave-files are the most exotic stuff to be delivered, I
do not see a danger of being seriously hurt when working for a soundtrack.
Just get a generic MPEG or DV file of the movie. Convert it like this:
http://xjadeo.sourceforge.net/doc/ar01s03.html#video_formats
extract the soundtrack from the orignal file to a wav-file
open a new session in Ardour and import the basic soundtrack, make sure
that Ardours clock-source is set to "jack" and that it is time master.
start xjadeo like this:
xjadeo file_converted_as_seen_above.avi
Here starts the fun-part. The movie in xjadeo will follow every move of
the cursor in Ardour (it will sync to any other jack-capable
timline-oriented app as well...)
Exporting the session to a format, that the videomakers prefer could be
somewhat more challenging then to export a classic stereo-file for CD/LP....
Dolby-Surround encoding and the like are a completely different matter
good luck ;-)
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksXtbAACgkQ1Aecwva1SWNr/QCdGh1pluAZ8EqQ/v2/eCsKVZN2
5OYAn1G0tqZA632WOKv+sntAYoUxHSOA
=666n
-----END PGP SIGNATURE-----
1:26 p.m.
Hartmut Noack <zettberlin(a)linuxuse.de> writes:
Just
Not to break your balls, but you actually responded to the author of
Ardour;).
Besides, JACK-VIDEO is part of the final solution. Xjadeo pales a little
in comparison;). It's a great tool and I've used it a lot, but don't
forget the dream..
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
sip:b0ef@ e e
jid:b0ef@ n n
2:34 p.m.
On Thu, Dec 03, 2009 at 07:24:57PM +0100, Esben Stien wrote:
Hartmut Noack <zettberlin(a)linuxuse.de> writes:
Besides, JACK-VIDEO is part of the final solution.
Does any such thing actually exist? I remember some years ago someone
had created some patches that turned the existing jack into a video jack
thing, but they weren't accepted since the approach wasn't considered
correct by the jack devs.
Is that what you are talking about when you say JACK-VIDEO?
or some later development?
or something not yet in existence?
-edrz
3:39 p.m.
Eric Dantan Rzewnicki <eric(a)zhevny.com> writes:
Does any such thing actually exist?
Yes. Indeed.
Is that what you are talking about when you say
JACK-VIDEO?
http://www.piksel.org/videojack
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
sip:b0ef@ e e
jid:b0ef@ n n
30 Nov
30 Nov
9:56 p.m.
On 12/01/2009 08:39 AM, Paul Davis wrote:
On Mon, Nov 30, 2009 at 4:11 PM, Atte André Jensen
<atte.jensen(a)gmail.com> wrote:
Come on, it's not that bad.
You can even sync blender with ardour and xjadeo at the same time if you
want.
Patrick Shirkey
Boost Hardware Ltd
Hi
A friend of mine has invited me to compose for some videos he's planning
on making. We haven't started yet, but I thought it might be good to be
a bit ahead, especially since I haven't done this before and I know next
to nothing about video...
The noise making apps will be running ontop of jack. Google suggest I
should look into xjadeo with the -i switch. Is that it? Anything
(formats, codecs, framerates, interlaces other-stuff-I-dont-get) that I
should ask for or try to avoid?
do you enjoy being whipped repeatedly by leather 9-tailed whips spiked
with stainless steel blades? no, i thought not. well, sign up for
that, because its going to be more enjoyable than the video thing.
possibly even a *lot* more enjoyable.
_____________________________________________
__
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
1 Dec
1 Dec
2:44 p.m.
Hi Atte,
> A friend of mine has invited me to compose for
some videos he's planning
> on making. We haven't started yet, but I thought it might be good to be
> a bit ahead, especially since I haven't done this before and I know next
> to nothing about video...
>
> The noise making apps will be running ontop of jack. Google suggest I
> should look into xjadeo with the -i switch. Is that it? Anything
> (formats, codecs, framerates, interlaces other-stuff-I-dont-get) that I
> should ask for or try to avoid?
>
My experience so far was not about a full-fledged multichannel 5.1
soundtrack but with a sonification of a silent film
(http://vimeo.com/7317445 and a brief 'experience report' here:
http://lists.linuxaudio.org/pipermail/linux-audio-user/2009-September/06298…)
After getting used to it using xjadeo which simply synced with ardour,
rosegarden and any Jack-transport-enabled app was a charm.
> do you enjoy being whipped repeatedly by leather
9-tailed whips spiked
> with stainless steel blades?
But keep in mind that the 'video-hell' is
not just linux: my colleagues
use a very expensive final-cut and they're still always having touble
with framerates, aspec ratios, codecs, etc. etc.
Much also depends, I think, on the kind of film (short movie, full film,
documentary) and what kind of work /you/ have to do (music only, all
soundtrack etc.)
Kind regards,
Lorenzo.
2:50 p.m.
On Mon, Nov 30, 2009 at 3:39 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
do you enjoy being whipped repeatedly by leather
9-tailed whips spiked
with stainless steel blades? no, i thought not. well, sign up for
that, because its going to be more enjoyable than the video thing.
possibly even a *lot* more enjoyable.
lau needs a "best of," b/c this would certainly be it. :)
--
Josh Lawrence
http://www.hardbop200.com
5:02 p.m.
Paul Davis wrote:
do you enjoy being whipped repeatedly by leather
9-tailed whips spiked
with stainless steel blades? no, i thought not. well, sign up for
that, because its going to be more enjoyable than the video thing.
possibly even a *lot* more enjoyable.
Couldn't find my 9-tailed whip, so I installed xjadeo instead :-)
Quick test with a couple of random files (one dv, one mp4) I had on my
hard drive, suggests it Just Works. Using the -K option get's rid of
that funny blurry digital soup that I've seem sometime before. Syncs to
jack same with renoise, so starting/stopping in either renoise or
qjackctl starts/stops the video. Playback of the video *seems* to be
started at the right spot when I move around in renoise.
I know this might come back as a boomerang, and make me look harder for
my whip. For instance I still have to see what format the video guy
sends me. Also I imagine to more precise sync I need the easier I'm
gonna be disappointed.
--
Atte
http://atte.dk http://modlys.dk
30 Nov
30 Nov
6:31 p.m.
2009/12/1 Atte André Jensen <atte.jensen(a)gmail.com>
Hi
A friend of mine has invited me to compose for some videos he's planning
on making. We haven't started yet, but I thought it might be good to be
a bit ahead, especially since I haven't done this before and I know next
to nothing about video...
The noise making apps will be running ontop of jack. Google suggest I
should look into xjadeo with the -i switch. Is that it? Anything
(formats, codecs, framerates, interlaces other-stuff-I-dont-get) that I
should ask for or try to avoid?
Any input, including links, tips, thoughts, would be highly appreciated!
:O
You're asking for a walkthrough on Sound for Film!
To start you off, frame rate is the most important. But of course, on Linux,
we have more than enough tools to convert foreign sources into workable
formats. On something like Pro Tools, if there is a frame rate mismatch with
source and project, the track's apparent rate will be highlighted in red.
Formats, Codecs: You are limited to what the video syncing application
supports, but it's not a big issue since you don't need to worry about it.
Again, frame rate _is_ an issue and we assume it is taken care of properly
when converting.
(De)interlacing: Nothing to do with audio, but you should get to know it.
xjadeo + ardour isn't the most intuitive of workflows, but for some people
it just works :)
--
GPG/PGP ID: B42DDCAD
1 Dec
1 Dec
9:54 a.m.
Atte André Jensen wrote:
A friend of mine has invited me to compose for some
videos he's planning
on making. We haven't started yet, but I thought it might be good to be
a bit ahead, especially since I haven't done this before and I know next
to nothing about video...
The noise making apps will be running ontop of jack. Google suggest I
should look into xjadeo with the -i switch. Is that it? Anything
(formats, codecs, framerates, interlaces other-stuff-I-dont-get) that I
should ask for or try to avoid?
Any input, including links, tips, thoughts, would be highly appreciated!
I've been exploring the world of Linux-based NLEs for a while, perhaps
you'll be interested in these articles:
http://www.linuxjournal.com/content/introducing-openshot
http://www.linuxjournal.com/content/kdenlive-meets-studio-dave
http://www.linuxjournal.com/content/it-lives-video-editing-foss-movie-makers
A profile of CinelerraCV will be up soon. I'm also putting the finishing
touches to profiles about Blender, PiTiVi, OpenMovieEditor, Avidemux,
and Kino.
At what stage(s) are you involved ? Will you only be composing the music
or will you be involved with the audio/video post-production ? The music
composition part isn't so tough, the post-production can be rather
bewildering. You'll select different formats and options to accommodate
your intended targets, and target formats depend on purpose and
residence, i.e. is it a polished demo for a DVD, a low-res clip for
YouTube/Vimeo/Facebook/self-advertisement-tool-du-jour, a DV file
destined for a camcorder tape, or ... ?
HTH,
dp
1:18 p.m.
2009/11/30 Atte André Jensen <atte.jensen(a)gmail.com>om>:
Hi
A friend of mine has invited me to compose for some videos he's planning
on making. We haven't started yet, but I thought it might be good to be
a bit ahead, especially since I haven't done this before and I know next
to nothing about video...
The noise making apps will be running ontop of jack. Google suggest I
should look into xjadeo with the -i switch. Is that it? Anything
(formats, codecs, framerates, interlaces other-stuff-I-dont-get) that I
should ask for or try to avoid?
Any input, ..., thoughts, ....
If you get a final film, where all you have to do is to compose the
music for it,
I think you can do it, as long as you're able to play the (digitalized) video
and sync it with your audio-applications.
Render the complete composition with full (film) length as single audio file.
The video guy then should know how to add your music to the final film
and which audio-file-formats his program accepts.
Haven't done it myself however, so this is more a guess.
--
E.R.
5498
days inactive
5501
days old
linux-audio-user@lists.linuxaudio.org
23 comments
13 participants
participants (13)
-
Atte André Jensen -
Danni Coy -
Dave Phillips -
Emanuel Rumpf -
Eric Dantan Rzewnicki -
Esben Stien -
Florian Faber -
Hartmut Noack -
Josh Lawrence -
Lorenzo -
Patrick Shirkey -
Paul Davis -
Ray Rashif