Software
Tunnelling Media Over SSH
08.06.07 23:12 |
Permalink
If this site had a "just too cool" section, this next
bit would be the first one there. You're at the
office and want to play some tunes from your home
Mac. Do you set up a file server to access them? Or
maybe some streaming system? Try to hack
iTunes to share beyond the LAN?
Or just use SSH (which you're probably serving anyway). The trick is to cat the remote file over the SSH tunnel to a local media player that can read from stdin, like mpg123:
Or how about listening to every single MP3 on your system from anywhere in the world?
But you usually want something a little more specific, like a certain artist and here's where the Tiger goodness really shines:
A good way to find out all the available search criteria is to use mdls:
... or you can also use Finder to graphically construct the query with a Smart Folder and just copy/paste it from the Get Info window. A lot of the iTunes-metadata (rating, playcount etc) is not exposed to Spotlight so you'll have to do some XML parsing if you want to find stuff based on that (sounds like a fun weekend project, now that I think about it...).
None of this will of course work with the M4P files from iTS. Regular M4A's shouldn't be a problem if you just use faad2.
And yes, it also works with video, just get a video player that reads from stdin (and a fat uplink!):
Or just use SSH (which you're probably serving anyway). The trick is to cat the remote file over the SSH tunnel to a local media player that can read from stdin, like mpg123:
$ ssh remote.machine.com cat sometune.mp3 | mpg123 -
Or how about listening to every single MP3 on your system from anywhere in the world?
$ ssh remote.machine.com "find Music/ -name *.mp3 -exec cat {} \;" | mpg123 -
But you usually want something a little more specific, like a certain artist and here's where the Tiger goodness really shines:
$ ssh remote.machine.com mdfind "kMDItemAuthors == '*Isis*'" -0 | xargs -0 cat | mpg123 -
A good way to find out all the available search criteria is to use mdls:
> mdls /Users/filipp/Music/iTunes/iTunes\ Music/Ochre/Lemodie/03\ Sosacharo.mp3
/Users/filipp/Music/iTunes/iTunes Music/Ochre/Lemodie/03 Sosacharo.mp3 -------------
kMDItemAlbum = "Lemodie"
kMDItemAttributeChangeDate = 2006-09-02 16:30:07 +0300
kMDItemAudioBitRate = 320
kMDItemAudioChannelCount = 2
kMDItemAudioEncodingApplication = "LAME 3.96.1 --alt-preset insane"
kMDItemAudioSampleRate = 44100
kMDItemAuthors = (Ochre)
kMDItemComment = "Ben034Cd"
kMDItemContentCreationDate = 2006-06-27 11:13:02 +0300
kMDItemContentModificationDate = 2006-06-27 11:13:02 +0300
kMDItemContentType = "public.mp3"
[etc]
... or you can also use Finder to graphically construct the query with a Smart Folder and just copy/paste it from the Get Info window. A lot of the iTunes-metadata (rating, playcount etc) is not exposed to Spotlight so you'll have to do some XML parsing if you want to find stuff based on that (sounds like a fun weekend project, now that I think about it...).
None of this will of course work with the M4P files from iTS. Regular M4A's shouldn't be a problem if you just use faad2.
And yes, it also works with video, just get a video player that reads from stdin (and a fat uplink!):
MPEG4 video wouldn't play however, no matter what
options I tried. Should probably try it with MPEG4IP some day.
|
Updates on the 6200c
18.05.07 00:54 |
Permalink
A while back I reported about my experiences
with the ProCaster 6200c DVBc PVR device. I've
now done a bit more research into free playback,
transcoding and editing solutions and here are
some results:
* VLC will not play back the files. All you get is noise and no audio.
* ffmpeg/ffplay doesn't know what to do with them either. It recognizes the audio track, but only sees a subtitle track where the video data should be.
* MPlayer plays back the files fine, just without subtitles. This is really cool and should also mean that mencoder will work.
* Then I discovered these guys and a tool called ProjectX which seems to be somesort of crazy utility for different PVR formats. The remarkable thing about it is that it actually works, on a Mac, no less, allowing you to extract and demux video, audio and subtitle streams from AVR files. It even has pretty good editing capabilities with which you can specify more than one cut point at once (something that many simple editors don't actually do) so in theory you could use this to manually mark out ads, demux everything (it seems that subs are not exported during a partial/edited demux) and send the output for encoding to some other app.
It seems AVR is much more than a simple MPEG2 container I thought it to be before. It's more like a VOB, containing anything from video and subtitles to alternate audio tracks. Another interesting discovery I made while playing with ProjectX was that DVB actually supports text-to-speech. Here's a sample of the audio track of this clip. Notice how it's overlaid on top of the original audio.
This turned out to be a pretty interesting little experiment. It makes me think there's really no tool out there specifically for the Mac that does what I need. ProjectX was a really nice surprise, but since the biggest motivator for me in all of this is archival (the HD on the PVR is just filling up), then it's not quite what I need. Ideally we'd have a tool into which you through a batch of AVR's straight off the box, select the subtitle track and have it cut out the ads and encode a typical ~1mbit/s 720i high-quality XviD out of it. Even an easy-to-use AVR -> XviD/AVI batch-encoder would be a step in the right direction.
Maybe I'll just have to try and make one...
* VLC will not play back the files. All you get is noise and no audio.
* ffmpeg/ffplay doesn't know what to do with them either. It recognizes the audio track, but only sees a subtitle track where the video data should be.
* MPlayer plays back the files fine, just without subtitles. This is really cool and should also mean that mencoder will work.
* Then I discovered these guys and a tool called ProjectX which seems to be somesort of crazy utility for different PVR formats. The remarkable thing about it is that it actually works, on a Mac, no less, allowing you to extract and demux video, audio and subtitle streams from AVR files. It even has pretty good editing capabilities with which you can specify more than one cut point at once (something that many simple editors don't actually do) so in theory you could use this to manually mark out ads, demux everything (it seems that subs are not exported during a partial/edited demux) and send the output for encoding to some other app.
It seems AVR is much more than a simple MPEG2 container I thought it to be before. It's more like a VOB, containing anything from video and subtitles to alternate audio tracks. Another interesting discovery I made while playing with ProjectX was that DVB actually supports text-to-speech. Here's a sample of the audio track of this clip. Notice how it's overlaid on top of the original audio.
* D-Vision 3 - no contact. Not
with the AVR's or even the demuxed m2v's. This is
surprising because it's supposed to be a mencoder
frontend which in turn is based on MPlayer. Quite
frankly, I don't understand this program anymore.
It used to be good for stitching AVIs and stuff
but it just keeps getting weirder and weirder with
every release.
* ffmpegX will surely be able to
handle the demuxed material, but I just don't feel
like messing around with it tonight. Probably
won't handle avr directly since ffmpeg didn't.
* mencoder (compiled from SVN),
as guessed can crosscode the AVR directly, still
no subtitles, but it'll have to do for now:
./mencoder -oac mp3lame -ovc xvid -xvidencopts bitrate=1000 ~/test.AVR -o test.avi
This turned out to be a pretty interesting little experiment. It makes me think there's really no tool out there specifically for the Mac that does what I need. ProjectX was a really nice surprise, but since the biggest motivator for me in all of this is archival (the HD on the PVR is just filling up), then it's not quite what I need. Ideally we'd have a tool into which you through a batch of AVR's straight off the box, select the subtitle track and have it cut out the ads and encode a typical ~1mbit/s 720i high-quality XviD out of it. Even an easy-to-use AVR -> XviD/AVI batch-encoder would be a step in the right direction.
Maybe I'll just have to try and make one...
XLD - A Quick Review
16.05.07 16:30 |
Permalink
I ran into a situation where I had a music CD as a
single FLAC file with the tracks defined in a
cuesheet. The
generally-fabulous Max wouldn't do anything with
this combo (actually, it opened the .cue file,
but that was it). The
command-line FLAC decoder does support cue
indexes, but just as I was getting ready for
some shellscript/Automator mumbo jumbo, I decided to
pull a Google search for "flac cue os x" and
that's when I stumbled on this wonderful little
utility called XLD.
Very straight-forward stuff. It cracked open the cue sheet and bam:
Very straight-forward stuff. It cracked open the cue sheet and bam:
Even though it's name suggests XLD only deals with
lossless files, it also supports a number of lossy
formats. And ofcourse you get to tweak all the
necessary parameters, including all the stuff you're
used to in iTunes (thanks to Core Audio).
Wonderful stuff. It doesn't get much better than
this - something that does exactly what it's designed
for and does it well. Wait, it does - there's also a
commandline version! ;-)
QuickTime 7.1.6
08.05.07 14:42 |
Permalink
Two things about the latest QuickTime update I
haven't noticed having been mentioned anywhere:
The first one is easy, we can now view the frame number, or, if the movie has a timecode track, different timecode formats:
- Timecode and closed captioning display in QuickTime Player
The first one is easy, we can now view the frame number, or, if the movie has a timecode track, different timecode formats:
It seems this might be tied to Compressor 3's
ability to do non-destructive timecode overlays.
Closed captioning has still remained a mystery to me.
All I could find was a checkbox in the preferences:
It's a shame that Apple hasn't yet updated the
developer docs to explain the
new captioning features. Hopefully it will be
discussed at WWDC. We can always just do the good
old alternate Text Track and View > Choose
Language thing, but I think it's high time for
something a bit more sophisticated. Especially if
Apple ever wants to expand it's movie selling
business outside the US. Robust captioning support might even
help push QT as a viable distribution medium as
well.
iftop
06.05.07 11:31 |
Permalink
Wouldn't it be cool to know exactly what connection
is eating how much of your bandwidth? Now you can,
thanks to iftop.
It has many useful commands (like regex
filtering), just hit "h" to read about them. And
ofcourse I just *had to* build a universal package (it goes into
/usr/local/sbin) I discovered this little gem
through Neubia. more info from man
iftop.
Why I don't like Symbian
05.05.07 16:06 |
Permalink
Just a few points why I think Symbian in general, and
S60 in particular suck really bad. And I'm not alone in this:
* Windows-only. I wonder how well the web would have taken off it the servers and development tools for making webapps and homepages would have been Windows-only. Some wonderful people have made an effort to get a Symbian toolchain running on *NIXes but they're all hopelessly outdated since there's no support from Nokia. Emulators only run in Windows. Nokia (the biggest Symbian licensee) doesn't seem to care. I'm not saying this just because I'm a Mac user - who the heck builds a development platform and doesn't support the OS's developers like the most (ie UNIX)?
Recently there has been some developments in the Open Source realm on Nokia's part but but the platform and toolset itself is still completely Windows-centric.
* Lackluster toolset. For a long time there weren't any free IDE's available from Symbian or Nokia. If you wanted to start developing for Symbian, you had to start off by paying ~$300 for a copy of CodeWarrior. This is almost as bad as forcing everyone interested in image processing to buy a copy of Photoshop 3 for the price of the latest version. Then came Carbide Express.c++ (based on Eclipse), which is still (currently v1.2) extremely crippled compared to the commercial ones. No UI design tools, no on-device or crash debugging, no optimization tools. What kind of a company sets off to establish an "industry leading" platform and doesn't start with a free (never mind cross-platform) set of development tools? This is all especially lame considering that the S60 SDK is built around PERL, Python, Java, GCC and Eclipse - all of which are (by now) Open Source. I haven't tried this myself, but from what I've heard from other devs, Microsoft has the upper hand in this with Windows Mobile.
* Symbian C++. Gawd... where do I begin.... Apparently Symbian C++ evolved at a time when the C++ standard was undergoing heavy updating. But instead of following the emergin standard, they took their own route (a shortcut? I dunno...). For starters, they have 4 types of strings (TDesC, TDes, HBuf, HBufC), 3 types of constructors (ConstructL, NewL, NewLC), it's own threads (Active Objects), non-standard exceptions and a totally convoluted naming convention.
A language is a tool and a tool is supposed to be a productivity multiplier. It took me about a week to develop an J2ME RSS reader with OPML support, that also runs on S40 (and many other Java-enabled) devices while I've struggled for months to create a basic bitrate calculator using Cymbian C++.The first time I had to read a Symbian C++ program it seemed like the eighties all over again. Quite frankly, I find it down right offensive, that at a time when some platforms enable us to build a full-featured dating service in less than 2 weeks, grown men must toil over getting their hello worlds to work.
* Crummy documentation. OK, so all the sales talk has won you over and you want to sacrifice your life to developing Symbian apps. Where do you start? You go to the Symbian site and all you find is a list of courses and some London guy's contact information. Mmkay... Then you fish around some more and finally get to the Getting Started PDF which is mostly just a collection links, but it also shows you how to build (and nothing more) a UIQ app using Carbide Express from a Hello World template (comes with the SDK). The last 4 pages is just s listing of books you should buy. The best Symbian help I've found so far is from this Italian guy's homepage. Googling for "symbian tutorial" will not have a single symbian.com or nokia.com page among the first 2 pages of results.
* Weird names galore! Uikon, Eikon, Avkon - no, these are not the moons of some Klingon planet. CAknCaleMonthlyStyleGrid - there's a nice name for a calender view. Can you guess what CAgnAppt does?*
* Platform incompatibility (UIQ vs S60, 80, 90 etc). Generally not backwards-compatible (source nor binary). Emulator can't run native binaries (imagine having to have separate versions of Windows programs for Virtual PC!). This is one of my biggest gripes with Symbian and S60 - you build and test something on the emulator but you can be pretty sure it won't run on the actual device. This is completely unacceptable. OK, you have a different version of the OS for each hardware platform, but all of this should be transparent to the application.
* Extremely slow emulation. Sometimes emulating supposedly one of the most efficient OS's running on a 220 Mhz ARM processor w/ 10 MB RAM (a Nokia 6630) on a 2,4 Ghz Pentium w/ 512 MB RAM running Windows XP feels like you're doing the exact opposite. I don't even want to think about running this stuff through an x86 emulator (althought I think I've tried it a while back).
* The whole UID business. Why on earth do we need this? And why do they have to be cryptic hex strings (why not com.me.myapp)? Shouldn't the OS handle the identification of programs? Why would anyone want to leave this task to the developer? This leads us to our next point...
* Signing. So you got over all the hurdles and your app actually runs on a phone (congrats!). How do you distribute it? Put it on your website for download? Maybe get a deal with an operator to carry it? Sure, right after you get it signed by Symbian. Simply stupid. At the minimum, this will cost you $350 + some silly testing costs that aren't even listed (my guess is they're outrageous). The operators claim this keeps the mobile network clean of malware, but to me it seems more like a quick way to milk the developers. If this doesn't kill innovation, then I don't know what does.
* Windows-only. I wonder how well the web would have taken off it the servers and development tools for making webapps and homepages would have been Windows-only. Some wonderful people have made an effort to get a Symbian toolchain running on *NIXes but they're all hopelessly outdated since there's no support from Nokia. Emulators only run in Windows. Nokia (the biggest Symbian licensee) doesn't seem to care. I'm not saying this just because I'm a Mac user - who the heck builds a development platform and doesn't support the OS's developers like the most (ie UNIX)?
Recently there has been some developments in the Open Source realm on Nokia's part but but the platform and toolset itself is still completely Windows-centric.
* Lackluster toolset. For a long time there weren't any free IDE's available from Symbian or Nokia. If you wanted to start developing for Symbian, you had to start off by paying ~$300 for a copy of CodeWarrior. This is almost as bad as forcing everyone interested in image processing to buy a copy of Photoshop 3 for the price of the latest version. Then came Carbide Express.c++ (based on Eclipse), which is still (currently v1.2) extremely crippled compared to the commercial ones. No UI design tools, no on-device or crash debugging, no optimization tools. What kind of a company sets off to establish an "industry leading" platform and doesn't start with a free (never mind cross-platform) set of development tools? This is all especially lame considering that the S60 SDK is built around PERL, Python, Java, GCC and Eclipse - all of which are (by now) Open Source. I haven't tried this myself, but from what I've heard from other devs, Microsoft has the upper hand in this with Windows Mobile.
* Symbian C++. Gawd... where do I begin.... Apparently Symbian C++ evolved at a time when the C++ standard was undergoing heavy updating. But instead of following the emergin standard, they took their own route (a shortcut? I dunno...). For starters, they have 4 types of strings (TDesC, TDes, HBuf, HBufC), 3 types of constructors (ConstructL, NewL, NewLC), it's own threads (Active Objects), non-standard exceptions and a totally convoluted naming convention.
A language is a tool and a tool is supposed to be a productivity multiplier. It took me about a week to develop an J2ME RSS reader with OPML support, that also runs on S40 (and many other Java-enabled) devices while I've struggled for months to create a basic bitrate calculator using Cymbian C++.The first time I had to read a Symbian C++ program it seemed like the eighties all over again. Quite frankly, I find it down right offensive, that at a time when some platforms enable us to build a full-featured dating service in less than 2 weeks, grown men must toil over getting their hello worlds to work.
* Crummy documentation. OK, so all the sales talk has won you over and you want to sacrifice your life to developing Symbian apps. Where do you start? You go to the Symbian site and all you find is a list of courses and some London guy's contact information. Mmkay... Then you fish around some more and finally get to the Getting Started PDF which is mostly just a collection links, but it also shows you how to build (and nothing more) a UIQ app using Carbide Express from a Hello World template (comes with the SDK). The last 4 pages is just s listing of books you should buy. The best Symbian help I've found so far is from this Italian guy's homepage. Googling for "symbian tutorial" will not have a single symbian.com or nokia.com page among the first 2 pages of results.
* Weird names galore! Uikon, Eikon, Avkon - no, these are not the moons of some Klingon planet. CAknCaleMonthlyStyleGrid - there's a nice name for a calender view. Can you guess what CAgnAppt does?*
* Platform incompatibility (UIQ vs S60, 80, 90 etc). Generally not backwards-compatible (source nor binary). Emulator can't run native binaries (imagine having to have separate versions of Windows programs for Virtual PC!). This is one of my biggest gripes with Symbian and S60 - you build and test something on the emulator but you can be pretty sure it won't run on the actual device. This is completely unacceptable. OK, you have a different version of the OS for each hardware platform, but all of this should be transparent to the application.
* Extremely slow emulation. Sometimes emulating supposedly one of the most efficient OS's running on a 220 Mhz ARM processor w/ 10 MB RAM (a Nokia 6630) on a 2,4 Ghz Pentium w/ 512 MB RAM running Windows XP feels like you're doing the exact opposite. I don't even want to think about running this stuff through an x86 emulator (althought I think I've tried it a while back).
* The whole UID business. Why on earth do we need this? And why do they have to be cryptic hex strings (why not com.me.myapp)? Shouldn't the OS handle the identification of programs? Why would anyone want to leave this task to the developer? This leads us to our next point...
* Signing. So you got over all the hurdles and your app actually runs on a phone (congrats!). How do you distribute it? Put it on your website for download? Maybe get a deal with an operator to carry it? Sure, right after you get it signed by Symbian. Simply stupid. At the minimum, this will cost you $350 + some silly testing costs that aren't even listed (my guess is they're outrageous). The operators claim this keeps the mobile network clean of malware, but to me it seems more like a quick way to milk the developers. If this doesn't kill innovation, then I don't know what does.
... or just use one of the alternatives - Java, Python or Flash Lite.
* it's an appointment in the calendar.
Why I switched to Safari (again)
22.03.07 22:01 |
Permalink
I've been a big fan of Camino. Ever since it was
called Chimera. Whenever a new Mac OS would come out,
that I didn't have the hardware for, I could still
use a modern, native Mac browser thanks to them.
These guys have done a tremendous job bridging the
Gecko rendering engine with a OS X L&F that in
many ways feels more "Mac" than Apple's own browser.
I originally switched to Camino because:
I liked Camino because it eliminated most of my biggest problems with Safari, but now I'm forced to swtich back because:
In general, I'm not quite sure what to think of Camino anymore. Firefox is getting more and more Mac-like (to some extent) so maybe it would make sense for the two projects to just merge? That Camino would just be the Mac port of Firefox? Camino will run on anything starting with Jaguar which might be (?) a reason it's still so rough around the edges. It is my understanding that backwards compaitility often comes at a high price on OS X (although maybe not so much in Camino's case since it probably doesn't depend on OS services that much).
In any case, I replaced Camino with Safari in my Dock today. Bookmarks would've been trivial but let's be honest - who uses them anymore? del.icio.us, maybe. The biggest nag will actually be all the cookies that have already been set in Camino and the keychain items...
- Many JavaScript WYSIWYG HTML editors will just disregard Safari. And if you have to use two browsers sometimes, why not just completely switch to the one that does everything, right?
- It tries to render XML instead of showing me the tree
- Safari has a weird habit of tagging .txt to downloaded files it can't recognize
- Source view is very primitive with no highlighting and it also can't be reloaded.
- Bookmarks menu has to be one of the slowest in the world
- Downloads can't be opened with a double-click in the Downloads window. EDIT: Actually they can. Just click on the icon.
I liked Camino because it eliminated most of my biggest problems with Safari, but now I'm forced to swtich back because:
- Flash performance in Camino is just terrible. I tried to go around this by disabling it altogether, but in this YouTube day and age it's very difficult to do. And why should you? This got incredibly annoying at times - not being able to swtich tabs when a flash object was loaded in the frontmost window or having the whole app freeze for tens of seconds. Any kind of Flash content would also heaviliy bump Camino's CPU usage.
- Other plugins behaved oddly as well. Often an embedded QuickTime movie would stay inside every tab I would switch to. Clearly something's not right with the Gecko View.
- Window resize performance. I typically have about 10 tabs open at once and window resizing gets really slow. It's not disastrous, but definitely not something you would expect on a 2-year old Mac with 1,25GB RAM.
- Stability issues. Especially in the latest 1.1 branch which would regularly crash every day for me. Downloading the latest nightly seemed to help though.
- No AcidSearch. You can add search sites to Camino by editing an XML file but that won't give you the shorcuts that you have in Safari. This is clearly something that could be added to Camino but I personally have neither the skill nor the time and motivation to do this right now.
- Startup time. Clearly no biggie, but in this day and age you would expect your browse to come up instantly. Almost so with Safari, but not quite with Camino. Here're some completely bogus test results, Camino takes more like 5 secs to start up actually (open returns before all the NIBs are unpacked, I would guess):
> time open -a Camino
real 0m0.504s
user 0m0.080s
sys 0m0.073s
> time open -a Safari
real 0m0.272s
user 0m0.079s
sys 0m0.051s
In general, I'm not quite sure what to think of Camino anymore. Firefox is getting more and more Mac-like (to some extent) so maybe it would make sense for the two projects to just merge? That Camino would just be the Mac port of Firefox? Camino will run on anything starting with Jaguar which might be (?) a reason it's still so rough around the edges. It is my understanding that backwards compaitility often comes at a high price on OS X (although maybe not so much in Camino's case since it probably doesn't depend on OS services that much).
In any case, I replaced Camino with Safari in my Dock today. Bookmarks would've been trivial but let's be honest - who uses them anymore? del.icio.us, maybe. The biggest nag will actually be all the cookies that have already been set in Camino and the keychain items...