| 16:57 | <bga_> | http://www.google.com/patents?id=Szh4AAAAEBAJ&printsec=abstract#v=onepage&q&f=false |
| 17:54 | jgraham | is evidently too tired for the internet today |
| 17:55 | <wilhelm> | Unpossible. |
| 23:05 | <llrcombs> | could someone remind me if there are plans for a pasteboard manager in the HTML5/JS spec? |
| 23:13 | <heycam> | llrcombs, there's http://dev.w3.org/2006/webapi/clipops/clipops.html |
| 23:16 | <KaOSoFt> | heycam, thanks as well, didn't know that. |
| 23:16 | KaOSoFt | keeps reading |
| 23:18 | <llrcombs> | what do you pass to createEvent to make a clipboard event? |
| 23:30 | <llrcombs> | hmm, it doesn't seem to exist |
| 23:35 | <llrcombs> | is an <audio loop> supposed to have any pause whatsoever between when it ends and when it restarts? |
| 23:35 | <aho> | with mp3, yes |
| 23:35 | <aho> | otherwise no |
| 23:36 | <aho> | (mp3 always contains leading/trailing silence) |
| 23:37 | <llrcombs> | ahh |
| 23:37 | <llrcombs> | so with MP3, you'd need some timeupdate trickery? |
| 23:37 | <aho> | with mp3 you can forget about it :) |
| 23:38 | <aho> | wont work |
| 23:38 | <aho> | you'd need some cue in/out points... and then cut it off the decoded data... and then you can loop it |
| 23:38 | <aho> | so yea... forget about it :) |
| 23:38 | <zewt> | aren't there some tags for mp3 to indicate how much audio from the last frame to chop off for seamless looping/transitions |
| 23:38 | <aho> | you won't have this issue with ogg/vorbis or m4a/aac |
| 23:39 | <aho> | (there is no reason to use mp3 in browsers) |
| 23:39 | <llrcombs> | even if I detect when it's within <insert silence time here> of the ending using the timeupdate, then set currentTime to <insert silence time here>? |
| 23:39 | <aho> | the timing wont be accurate enough for this |
| 23:39 | <zewt> | you're not going to be able to cut off 5ms of audio that way |
| 23:40 | <llrcombs> | oh, it's that short |
| 23:40 | <zewt> | enough to cause a glitch |
| 23:40 | <llrcombs> | well, maybe the spec should say that the browser should cut out the silence using that tag |
| 23:41 | <aho> | it's 20-30msec iirc... well, even if you'd check every 1msec... it still wouldnt be accurate enough :> |
| 23:41 | <llrcombs> | when loop is true |
| 23:41 | <aho> | just dont use mp3 |
| 23:41 | <zewt> | well one, i don't recall for sure that it exists, and two, it's an ancient workaround for an obsolete file format--browsers shouldn't have to implement it (and they won't, anyway) |
| 23:41 | <llrcombs> | WebKit fires timeupdate every 200ms |
| 23:41 | <llrcombs> | or every keyframe, whichever's more frequent, iirc |
| 23:41 | <zewt> | "keyframe" is generally a video term and not very meaningful for audio codecs |
| 23:42 | <llrcombs> | yeah, that's why it's not applicable in audio |
| 23:42 | <aho> | mp3's size/quality ratio is worse than ogg/vorbis or m4a/aac and it doesn't loop |
| 23:42 | <aho> | just dont use it |
| 23:42 | <llrcombs> | but the webkit docs said that about media elements in general |
| 23:43 | <llrcombs> | is FLAC actually loads better in quality, or is that just audiophile sh*t? |
| 23:44 | <llrcombs> | also, what's the point of censoring curses when they're still obvious? |
| 23:44 | <llrcombs> | (or censoring curses at all, for that matter?) |
| 23:44 | <zewt> | are you just trying to think of questions to ask |
| 23:44 | <zewt> | heh |
| 23:44 | <llrcombs> | no, those all just came to mind in a strangely shaped train of thought |
| 23:44 | <AryehGregor> | When people say one audio format's quality is better, they're usually saying it can compress similar-quality sound better. |
| 23:44 | <llrcombs> | you can trace it back, if you want |
| 23:45 | <AryehGregor> | Not related to the audiophiles who claim to be able to tell apart lossless from high-quality lossy encoding. |
| 23:45 | llrcombs | looks forward to WebKit supporting <input type="file" accept="...capture..."> |