Comments for sampablokuper_com

Comment on tar cannot stat by Stephen

Stephen — Mon, 15 Feb 2010 16:21:56 +0000

Thanks!

And Erik, the v needs to be before the f as well

Comment on Environmentally friendly disposal of compact fluorescent light bulbs – a pragmatic approach by Nick Seeber

Nick Seeber — Tue, 26 Jan 2010 12:15:00 +0000

Long time no post however this is really useful, so thanks. I will be referring to it when my bulbs die…

Comment on Bundles of musical joy by sampablokuper

sampablokuper — Sat, 23 Jan 2010 21:33:48 +0000

Hm, I wonder if MGMT might be interested in my bundling ideas? http://www.guardian.co.uk/music/musicblog/2010/jan/20/bands-dont-miss-single-thing

Comment on svn revert to revision by maml

maml — Fri, 08 Jan 2010 18:07:07 +0000

@Ben – excellent dude. worked great for me.

Comment on Vim keybindings in Google Chrome? by chrome vim

chrome vim — Wed, 30 Dec 2009 04:57:20 +0000

recommend you Vrome

Features

Zoom

[count]zi zoom in [count]zo zoom out [count]zm zoom more [count]zr zoom reduce zz zoom reset

[count]zI Enlarge full zoom of current web page. Mnemonic: zoom in. [count]zM Enlarge full zoom of current web page by a larger amount. Mnemonic: zoom more. [count]zO Reduce full zoom of current web page. Mnemonic: zoom out. [count]zR Reduce full zoom of current web page by a larger amount.Mnemonic: zoom reduce. zZ Set full zoom value of current web page to 100%.

Page

]] next page [[ prev page Y copy selected text

Url

[count]C-a Increment last number in URL [count]C-x Decrement last number in URL [count]gu Go to the parent directory. gU Go to the root of the web site. gf view page source

o Open one or more URLs in the current tab,multiple urls can be separated with ", " Note that the space after the comma is required. O Show an :open prompt containing the current URL. t Just like :open but also uses a new tab for the first URL. T Show an :tabopen prompt containing the current URL.

Scroll

gg scroll to top G scroll to bottom 0 scroll to first $ scroll to last

[count]k scroll up [count]j scroll down [count]h scroll left [count]l scroll right [count]% scroll to percent [count]%

[count]C-f scroll to next page [count]C-b scroll to prev page [count]C-d scroll to next half page [count]C-u scroll to prev half page

Tab

r Tab.reload R Reload all tabs d Tab.close [count]u undo closing of a tab [count]C-p prev Tab [count]C-n next Tab [count]gt next Tab [count]gT prev Tab y copy current url g0/g^ Switch to the first tab. g$ Switch to the last tab. C-^ Select the previously tab.

History

[count]H History.back [count]L History.forward [count]C-o History.back [count]C-i History.forward

Hint

f start QuickHint mode F start QuickHint mode,but open link in a new tab.

/ forward search ? backward search [count]n find next ( out input box ) [count]N find previous ( out input box )

Enter find next ( in input box ) S-Enter find previous ( in input box ) * Search forward for the selected words

Search backward for the selected words

[count]gi focus the first input box in the current page C-z disable Vrome temporary C-v pass through next key [count]. Repeat the last command

Insert Mode

Esc blur focus C-[ blur focus

C-a move to first words or select all C-e move to end

C-d delete forward char C-h delete backward char

C-w delete backward word M-d delete forward word

C-u delete backward to the beginning of the line. C-k delete forward to the end of the line.

M-h move back a word M-l move forward a word M-j move back a char M-k move forward a char

Comment on Bundles of musical joy by Stephen

Stephen — Wed, 23 Dec 2009 23:05:00 +0000

I still don’t buy that they have to settle on one archive format, but never mind. (Another witness to my case: HTTP’s inclusion of an Accept-Encoding header for negotiating this sort of thing flexibly.) And grokking the archive (as opposed to its contents) should not really be the media player’s job either, in a closer-to-ideal world… but I digress.

I think the MIT license will do.

Comment on Bundles of musical joy by sampablokuper

sampablokuper — Sat, 19 Dec 2009 14:54:10 +0000

I take your point about the inconvenience of extracting problem. However, stores that sell music online still need to settle on an archive format (JAR, ZIP, whatever) and a standard structure within those files, in order for downloaded albums to be able to be reliably unpacked by users into a directory structure that media player software can grok, non?

Most music companies send their album sleeve and inlay card designs to the printers as PDF files, in my experience; this is another strong argument for having PDF as the default format for the artwork in album bundle files/directories.

Thanks for emailing me your script Since all my GNU/Linux boxes are down for the count right now ( partly to do with this not working quite as hoped), I won’t be able to try it in a hurry, but I’ve taken a look at the code. I see there’s no license embedded… did you have one in mind?

Thanks again.

Comment on Bundles of musical joy by Stephen

Stephen — Sat, 19 Dec 2009 14:25:47 +0000

Well I’m not sure I buy the “risk of separation” argument, because the converse is “inconvenience of extracting part” and that’s a far more likely case. Everyone keeps files in directory structures on their computer, and “losing things” once they’re in such a structure is rare. By contrast, it’s very likely that I might want to send someone just one song from an album (or just the artwork). Of course Java can run JARs… but it can also run class files in a directory structure, so that’s more of an argument for “support many”. On the other hand I do buy the adoption argument, but purely for nontechnical (and moreover fairly short-term and circumstantial) reasons.

(Humans have tendencies towards overspecialisation as well as overgeneralisation… I’m trying to counter the former!)

I suppose PDF versus HTML+images comes down to whether the source encoding is vector or raster… and the vector case is very plausible. On the other hand, there’s no free software for rendering fancier PDFs yet, so that’s a [short-term, circumstantial] argument for HTML.

My ripping script can encode however you want — the encoder command is a parameter. It’s not very cross-platform though… it definitely requires a Unix-like environment, and getting the ISO images out pretty hard to make portable, so it’s done with Linux-only cdfs at the moment. Hmm, maybe plain old dd would work….

Comment on Bundles of musical joy by sampablokuper

sampablokuper — Tue, 15 Dec 2009 13:56:23 +0000

Thanks for clarifying your point about directories. My main reason for suggesting an archive format is that this way you wouldn’t need to unpack your album downloads. After all, if media player software can play directories and if Java can “play” .jar files, why can’t media player software play archive files? Also, keeping the whole lot – music and inlays – bundled in one file is much like keeping, say, a CD and inlay in a CD case: you reduce the risk of them becoming separated. Finally, having one file per album (albeit with the ability to ask your media player to copy out individual tracks on demand) is probably more manageable for most folks than maintaining a file tree per album, especially a file tree with a range of different file types. The latter situation is pretty much the current one, and I think it encourages a lack of standardisation that reduces, rather than promotes, the likelihood of online retailers selling records (rather than just tracks) in a standard format.

In favour of your point, though, there’s some discussion on the WHATWG mailing list about making it easier to upload/download directories rather than just files.

As for having artwork stored as HTML, I think that’s also not quite ideal. Album artwork tends to be laid out very precisely, something for which HTML is a notoriously poor format (though admittedly image maps lay out more reliably than most elements), not least because of browser shortcomings. Hence my advocation of PDF.

I look forward to seeing it your CD-ripping script. If it can be written in some cross-platform way, and if it can output both FLAC and VORBIS (I like to bifurcate: a full-quality copy for archiving/reference and a lossy-compressed copy for portable players with limited space), so much the better

Comment on Bundles of musical joy by Stephen

Stephen — Tue, 15 Dec 2009 11:37:41 +0000

I was just saying that you don’t need to dictate how the directory structure is encoded — that doesn’t mean you couldn’t encode it at all. But if I like tar files and you like zip files, that’s no reason for one or other of us to be violating the spec. The player and/or operating system can work out the choice of encoding quite easily. In fact I’d probably want to keep my “albums” in a completely unarchived form, just as directory trees on my hard disk — except when sending them around to people. Then an archive is more convenient, although only because our software does “send file” but not “send directory structure”. By contrast, good media player software does understand how to “play a directory”, not least because DVDs are most easily ripped into a verbatim (de-CSS’d) directory tree.

I was envisaging the artwork could be encoded as a mixture of HTML (probably just image-maps) and images. I imagine Flash would be many people’s choice though….

My CD-ripping script is not yet available, as its interface is a bit esoteric at the moment. But I’ll take that as a request to put it out there sooner rather than later! I have tons of scripts I really should put on the web.