Re: [Pykaraoke-discuss] [HOWTO] Implementing pitch-shifting and crossfading (for filler music/other sources) for PyKaraoke on Linux with JACK

2006-04-10 Thread Jay R. Ashworth
On Sat, Apr 08, 2006 at 11:19:22AM -0600, William Ferrell wrote:
  [ lost address; pressed for time; please reply back onto list? ]
 
 Not a problem :) I've done that before ;)

Tnx.

  On Fri, Apr 07, 2006 at 08:06:06PM -0600, William Ferrell wrote:
   On 4/7/06, Jay R. Ashworth [EMAIL PROTECTED] wrote:
On Fri, Apr 07, 2006 at 12:29:58PM -0600, William Ferrell wrote:
 This HOWTO attempts to document how the whole thing fits together, how
 to implement it on your own system, and how to use it in production at
 a karaoke (or really any DJ'ed) show.
   
This is really spiffy.  I'm not sure how easily I'm going to be able to
integrate it with the control-top I want to construct (which I've
finally, at least, sketched out, and am trying to learn Glade to mock
up), but...
  
   Yeah, I'm still trying to get some of the interface elements down
   better. It's usable right now thanks to Enlightenment but it could
   definitely be better.
 
  I will Try Really Hard to get a mock up of my design into a format you
  can look at, this week.
 
 Excellent, thank you!

Even if I have to do it in CorelDraw.  :-)

Are there any good interface mockup programs?

Specifically, it can talk to my Phase 26 USB box, with 3 stereo outputs
(I'm very much a real mixing board kind of guy).
  
   Ooooh, spiffy :) I likey :)
 
  Terratec, specifically.  Has a simultaneous input as well, with a mic
  pre.
 
 I need to dig around and find one of these; this takes me a step
 closer to an all-digital show.

I got mine from JB on eBay; $150, I think.

   The site claims it can be controlled via the ALSA sequencer, though,
   so it looks like it's possible.
 
  Ok.  In my case, again, it's because I want the control surface to be
  all-encompassing; I'm planning on a 17 touchscreen (with a
  micro-keyboard for entering search terms, optionally -- you could do it
  with a popup keyboard).
 
 [droolification]

You've been watching Wicked too much... :-)

And, BTW; kudos on the site; blogging with MW isn't easy.
  
   Thanks, and you're right, it's a pain in the ass. I had to modify code
   to make that work. I'm tempted to switch it to Plone instead.
 
  I was looking at using Category tags, and a custom extension based on
  DPL 2, to do it myself.  Cause having each entry be a first-class
  article is useful as hell.
 
 http://willfe.com.nyud.net:8080/index.php/My_MediaWiki_Hacks
 
 Go read that -- it describes what I did to implement exactly what you
 describe. And I hacked DPL2 ;) so that's exactly what you want. I'm
 using Categories to tag things, too, and all entries are first-class
 articles.

Spiffy cool.

 The link is Coral Cache-ified by the way because I'm expecting heavy
 traffic in a few days; a not-so-friendly company is threatening to sue
 me because I posted my experience with them on my site, and
 negotiations broke down recently. I went public with the details, and
 Tom Martino (the Troubleshooter) is going to have me on his radio
 program Monday to hash this stuff out. Heh. This should get
 interesting fast :)

Can't wait to hear how *that* goes...

Cheers,
-- jra
-- 
Jay R. Ashworth[EMAIL PROTECTED]
Designer  Baylink RFC 2100
Ashworth  AssociatesThe Things I Think'87 e24
St Petersburg FL USA  http://baylink.pitas.com +1 727 647 1274

 A: Because it messes up the order in which people normally read text.
 Q: Why is top-posting such a bad thing? 
 
 A: Top-posting.
 Q: What is the most annoying thing on Usenet and in e-mail?


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Pykaraoke-discuss mailing list
Pykaraoke-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss


Re: [Pykaraoke-discuss] [HOWTO] Implementing pitch-shifting and crossfading (for filler music/other sources) for PyKaraoke on Linux with JACK

2006-04-10 Thread Kelvin Lawson

Here's a curious idea: I wonder how hard it would be to recast Kelvin's
rendering code as an Mplayer codec?  Did we already talk about this?


I've fancied doing this for some time but haven't got round to it yet. 
Making an mplayer/ffmpeg codec would give you CD+G for free with a whole 
bunch of video players, as well as those commercial DVD players and 
other devices that use ffmpeg.


I'd need to rewrite it in C but it should translate fairly easily, 
especially given what we now know about CD+G.


Kelvin.


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Pykaraoke-discuss mailing list
Pykaraoke-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss


Re: [Pykaraoke-discuss] [HOWTO] Implementing pitch-shifting and crossfading (for filler music/other sources) for PyKaraoke on Linux with JACK

2006-04-10 Thread Kelvin Lawson

In fact the only missing piece apart from digital mixing is a lack of
straight-from-CD CD+G player, which is something I'm interested in
doing anyway, and I think Python can do it. Any hints or thoughts,
Kelvin?


I've given it some consideration in the past but not in great detail. 
Pygame can play audio tracks on a CD but (unsurprisingly) there is no 
facility to read the subchannel data.


Initial thoughts on the simplest thing to implement would be to combine 
a cdrdao/cdgrip pass with pygame's CD playback. It's just a hack but it 
buys you something. After selecting a track, you spawn off a process to 
rip just the CD+G data without any MP3 encoding. You can then play this 
back as usual with pycdg.py while the CD track plays. Should be 
relatively quick to implement but you pay the price of the time spent 
doing the rip before playback.


Doing it *properly*.. that's a different thing. I don't know, for 
instance, what the usual method would be for extracting the subchannel 
data on Linux. Whether you'd need to use a library like cdrdao, or 
whether it's just as easy to get what you need straight from the OS. I'm 
thinking something like Python bindings for cdrdao to read the 
subchannel data - and if you're doing this in real time then presumably 
you'd want to read the audio data at the same time, rather than have two 
proceses seeking around the disk. I'd need a deeper look into the likes 
of cdrdao to comment any further than that.



The link is Coral Cache-ified by the way because I'm expecting heavy
traffic in a few days; a not-so-friendly company is threatening to sue
me because I posted my experience with them on my site, and
negotiations broke down recently. I went public with the details, and
Tom Martino (the Troubleshooter) is going to have me on his radio
program Monday to hash this stuff out. Heh. This should get
interesting fast :)


Itching to hear how this pans out.

Kelvin.


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Pykaraoke-discuss mailing list
Pykaraoke-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss


Re: [Pykaraoke-discuss] [HOWTO] Implementing pitch-shifting and crossfading (for filler music/other sources) for PyKaraoke on Linux with JACK

2006-04-10 Thread Jay R. Ashworth
On Mon, Apr 10, 2006 at 09:34:00PM +0100, Kelvin Lawson wrote:
[ I said: ]
 Here's a curious idea: I wonder how hard it would be to recast Kelvin's
 rendering code as an Mplayer codec?  Did we already talk about this?
 
 I've fancied doing this for some time but haven't got round to it yet. 
 Making an mplayer/ffmpeg codec would give you CD+G for free with a whole 
 bunch of video players, as well as those commercial DVD players and 
 other devices that use ffmpeg.

Good point; I hadn't thought about shoving it down the extra layer.

Removing all the SDL glue would probably make my integration work
easier, too...

 I'd need to rewrite it in C but it should translate fairly easily, 
 especially given what we now know about CD+G.

Which, presumably, is more than you did before the first cut.  :-)

 In fact the only missing piece apart from digital mixing is a lack of
 straight-from-CD CD+G player, which is something I'm interested in
 doing anyway, and I think Python can do it. Any hints or thoughts,
 Kelvin?
 
 I've given it some consideration in the past but not in great detail. 
 Pygame can play audio tracks on a CD but (unsurprisingly) there is no 
 facility to read the subchannel data.

Hmmm... Is there a standardized way to get raw tracks off a Redbook CD
in Linux?  Doesn't XMMS do some of this?

 Initial thoughts on the simplest thing to implement would be to combine 
 a cdrdao/cdgrip pass with pygame's CD playback. It's just a hack but it 
 buys you something. After selecting a track, you spawn off a process to 
 rip just the CD+G data without any MP3 encoding. You can then play this 
 back as usual with pycdg.py while the CD track plays. Should be 
 relatively quick to implement but you pay the price of the time spent 
 doing the rip before playback.

Could you sync it, though?

 Doing it *properly*.. that's a different thing. I don't know, for 
 instance, what the usual method would be for extracting the subchannel 
 data on Linux. Whether you'd need to use a library like cdrdao, or 
 whether it's just as easy to get what you need straight from the OS. I'm 
 thinking something like Python bindings for cdrdao to read the 
 subchannel data - and if you're doing this in real time then presumably 
 you'd want to read the audio data at the same time, rather than have two 
 proceses seeking around the disk. I'd need a deeper look into the likes 
 of cdrdao to comment any further than that.

That sounds like a higher-difficulty task than the first one.  :-)

 The link is Coral Cache-ified by the way because I'm expecting heavy
 traffic in a few days; a not-so-friendly company is threatening to sue
 me because I posted my experience with them on my site, and
 negotiations broke down recently. I went public with the details, and
 Tom Martino (the Troubleshooter) is going to have me on his radio
 program Monday to hash this stuff out. Heh. This should get
 interesting fast :)
 
 Itching to hear how this pans out.

aol

Cheers,
-- jra
-- 
Jay R. Ashworth[EMAIL PROTECTED]
Designer  Baylink RFC 2100
Ashworth  AssociatesThe Things I Think'87 e24
St Petersburg FL USA  http://baylink.pitas.com +1 727 647 1274

 A: Because it messes up the order in which people normally read text.
 Q: Why is top-posting such a bad thing? 
 
 A: Top-posting.
 Q: What is the most annoying thing on Usenet and in e-mail?


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Pykaraoke-discuss mailing list
Pykaraoke-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss


Re: [Pykaraoke-discuss] subcode and deinterleaving question

2006-04-10 Thread Kelvin Lawson

Hi Drew,


I've been reading all the info I can find but I must admit I'm getting a
little confused partly because the terms frame and sector do not
seem to be used consistently. For instance the ECMA-130 standard seems
to refer to 588 bits burnt on to the disk as a frame.


Thanks for the headsup, I hadn't seen that ECMA 130 before. I thought 
the gory details were to be found in the Red Book which costs money, so 
it's great to find this info available for download.


I've just had a scan through it, and it distinguishes between sections, 
sectors and frames. We've used sector and frame to describe the same 
thing in the cdgtools code - as the 2352 bytes of audio + (2 * 392) 
bytes error correction/detection + 98 bytes subchannel data. Looks like 
we should replace frame by sector throughout the code.


Some of the above is filtered out to get the data returned by cdrdao. We 
get the 2352 bytes of audio data, plus 96 bytes of subchannel data. (The 
first two bytes of subchannel data appear to be sync bytes, hence 
getting 96 instead of 98). The subchannel data is contained in the 
control byte discussed in the document.



I know a certain amount of interleaving goes on in the audio data prior
to it being written onto the disk but I was under the impression that
the same could not be said about subcode?


It looks that way from the document. The CIRC coding is done before the 
control bytes are added, but perhaps the control bytes are then added in 
the relevant place, i.e. they are not added in order because they are 
placed according to the position of the CIRC-encoded data? I haven't 
read deeply enough yet to figure that out.


As you can probably tell from the above, I'm pretty much in the dark 
about the interleaving process. When writing cdgtools I noticed that my 
drive was returning data that looked almost correct but with the bytes 
spread around. I couldn't find any information on the interleaving 
process, and believed it to be in the Red Book, but came across the 
following:


http://club.cdfreaks.com/showpost.php?p=719361postcount=13

This guy was in the same position as me, but had the patience to sit 
down and reverse engineer which bytes went where.



Is it just the r to w channels which are interleaved or is it the whole
subcode byte? (including the p and q channels).


I'm not sure because I mask out only the P and Q subchannels. Are you 
asking because the CIRC section discusses encoding of P and Q bytes? The 
way I read that was that these are parity bytes, unrelated to the p-w 
subchannels (confusing terminology).


My (probably flawed) thinking is that the control bytes containing 
subchannel data are not put through the CIRC process, but are matched up 
with the new position of the relevant frame after CIRC encoding, and so 
are effectively interleaved. Bear in mind I don't even know if the 
deinterleaving code in cdgtools is actually reversing the CIRC 
cross-interleaving, or if it's some other magic altogether. It would be 
great if you had the time and inclination to check this out :-)


Hope that helps,
Kelvin.


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Pykaraoke-discuss mailing list
Pykaraoke-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss