| yip yip yip! brrrrringtone.... |
[Jan. 7th, 2010|01:56 am] |
How about that. Your childhood memories inserted into a "snazzy" mp3 ring tone. Less than 30 seconds so I guess it counts as fair use. Created using samples from a video ripped off from youtube (thanks Google!) and a free sound bite snarfed from freesound.org and slapped together with audacity. Pretty good for an hour or so worth of fiddling - if I do say so myself.
Download Ring tone
|
|
|
| ofx ssl |
[Feb. 29th, 2008|03:00 pm] |
I wanted to record this somewhere, this seemed like a decent place. :)
Innovision Financial Server is a java based application server solution that can handle OFX transactions. Generally that's what Quicken (and other financial software) uses to directly download financial info from your bank or broker.
Nepal was designed for use on Windows machines. It's obvious in the command line interface. It also doesn't work when trying to import the certificate reply. Every time I've tried to manage this thing using their instructions and their tools it fails horribly. So instead, one would be smart to start off using keytool for the whole thing.
I wasn't, but that's fine.. their product works okay for generating the CSR at least.
When you get the reply, you need to add the certificate chain to the reply. There will likely be an intermediate certificate which signs your cert and then a root certificate which signs that one.
Just copy/paste the contents PEM encoded contents of both files right above the certificate reply.
$ cat cacert1.crt cacert2.crt certreply.crt > cert.crt
Import everything into the keystore: (the alias is always "serverid" with Innovision Financial Server)
$ keytool -importcert -alias serverid -file cert.crt -keystore keys
Replace the old keys file with your new one, restart the ofx server and you're on your way to client-server security bliss. |
|
|
| Hear exactly what you're missing in your mp3s |
[Aug. 1st, 2007|01:31 pm] |
| [ | Current Location |
| | Home | ] |
| [ | mood |
| | distracted | ] |
I was curious one day to know how different qualitatively an MP3 encoded audio track sounded from the original CD. I took a song from one CD and then encoded it with lame on default settings then encoded it with lame on extreme settings. I used audacity to subtract the mp3 waveform from the original. The stuff that's left over is what the encoder left out when it encoded the track.
For your listening pleasure here's a 10 second hunk of track as ripped from CD. Please be gentle, these are hosted on my home internet connection.
Here's the what's left when a standard encoded mp3 is subtracted from the original.
This is what that sounds like using extreme encoding.
Interesting? Maybe.
To do this:
1. rip a track with cdparanoia
2. encode once with lame on 'default' settings
3. encode once with lame on 'extreme' settings
4. fire up audacity and load the original wav and one of the mp3 files
5. split each track into right and left.
6. remove the right channel
7. copy the left mp3 channel into the left wav channel window
8. invert the mp3 channel
9. zoom way in so you can precisely align the tracks. This one had lots of clipping (yay for modern recording techniques) so there were plenty of places where the waveform came to full value and made aligning easy.
10. Set each track as mono instead of left channel.
11. Do a "quick mix" operation.
12. profit!
Now you can hear what your encoder is dropping from the original. To me, the most interesting is the difference between extreme and standard. On standard the music almost sounds like a really crappy approximation of the original. On extreme all you really hear is extreme highs and some very few lows so lots of the information seems to stay. |
|
|
| Converting sound files to images -- the long way. |
[May. 25th, 2006|05:24 pm] |
| [ | Current Location |
| | Limbo | ] |
| [ | mood |
| |  stressed | ] |
| [ | music |
| | None | ] |
Probably been done many times before, but I was inspired by this post which discusses pumping random data files out your speakers directly via /dev/dsp.
Well that made me think about going the other way. Taking a sound file and turning the bits into a viewable image without much more than throwing the appropriate header on the file.
So I scoured my system for the biggest wav file.
$ locate .wav | xargs du | sort -rn | head -1
956 /usr/share/sounds/KDE_Startup_new.wav
I think .wav is pretty close to raw sound data, but that's probably a false assumption.
First, a little light reading to help figure out the BMP spec.
Then figure out how big this image will be given the data size:
970882 bytes * 8 = 7767056 bits / 32 = 242720 pixels ^ (1/2) = 492 pixels^2
Then I fired up a hex editor, added the appropriate bits in the appropriate places.
And I have my bmp file header: kdehead.bmp (note: if you want to see it, save the file and view with a hex editor, instead of clicking, it doesn't have any image data and might break an unforgiving image library)
And here's the original wav file: KDE_Startup_new.wav
Conatenate the files together like so:
$ cat kdehead.bmp KDE_Startup_new.wav > kde.bmp
VI-OLA, an image of data. Looks about as interesting as your random block of data sounds, but I think it's cool anyway.
I suppose I limited myself a bit as any old chunk of bits at all could be turned into an image, maybe I'll try it on /proc/kcore next! Hmm, it's around a gigabyte, even at 32bpp, that's 16319 pixels squared! |
|
|
| Runs With Newts |
[Nov. 3rd, 2005|10:10 am] |
| [ | Tags | | | newty, nicknames | ] |
| [ | mood |
| |  good | ] |
| [ | music |
| | De La Soul - 3 Feet High and Rising | ] |
Apple Tree Root Trip - AKA Apple T[a]RT
Riptide - AKA C:<ENTER>###
These are all just strings of characters to most people. However, Newty is in the house. |
|
|
| heisenscript - or - jpg2mpg |
[Mar. 2nd, 2005|02:33 pm] |
Seeing no entries in google for heisenscript, I hereby coin the phrase. :) I'm sure others have thunk it before but too bad, they didn't blog it on a popular blog site. Not that THIS blog is popular, far from it! But livejournal itself is fairly popular and carries lots of weight with Google I'd imagine.
I've been running Debian testing (currently Sarge), with Motion and just dumping the pictures to a directory for later processing.
I created a small script to rename the files from the normal format of nn-yyyymmddhhmmss-ff.jpg to something ffmpeg can handle img%06d.jpg
Here's the exact code for your perusal:
$ cat ~/bin/jpg2mpg
#rename
c=0;for i in `ls | grep jpg | sort -t\- -k 2,3 -n`;do j=`printf "img%06d.jpg" ${c}`; c=$(($c + 1)); mv $i $j; done
#encode
/home/meyerdg/video/ffmpeg-0.4.8/ffmpeg -i img%06d.jpg `date +%d%b%Y`.mpg
There may be a way to get Motion to put image names in another format, but I haven't invested any time in it. :) This works.
Also, Motion's supposed to be able to make its own mpegs of each event. I didn't want lots of separate movies for each separate event. I want one that runs the whole day long. This works. Right now I get around 12,000 images per day. 15.5k per image, around 230-250MiB per day isn't too bad. It scrunches down to 6MB in mpeg format so all in all pretty easy to maintain.
The interesting part came the other day when I was renaming a batch of files.. some of them came up missing after a second batch was added and appended to the end. At first, (naturally) I blamed my system. :) Strange thing was that every file with the consecutive digits "128" in them were missing. (img000128.jpg, img001128.jpg, etc...)
Heisenscript was mentioned when I thought I could figure out which part of my system was failing. Except if I changed anything would the entire behavior change? Would watching or measuring what happened cause differences in the results? The answer apparently is yes... but not for the reasons I thought at first.
More later.... |
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| |
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
d1663m's journal