| 00:29:33 | fs-bluebot | Build Server message: New build round started. Revision dafc359, 217 builds, 21 clients. |
| 00:33:09 | | Quit bertrik (Remote host closed the connection) |
| 00:35:21 | fs-bluebot | Build Server message: Build round completed after 349 seconds. |
| 00:35:22 | fs-bluebot | Build Server message: Revision dafc359 result: All green |
| 00:35:36 | | Quit ender` (Quit: The curious thing about .Net is that it allows you to use any language you want, as long as it's C#.) |
| 00:35:58 | pamaury | \o/ it compiles |
| 00:45:18 | | Join Scromple [0] (~Simon@119.225.209.134) |
| 01:00 |
| 01:22:00 | | Quit kaputnik_ (Ping timeout: 245 seconds) |
| 01:24:28 | | Quit pamaury (Ping timeout: 256 seconds) |
| 01:25:39 | | Quit TheLemonMan (Ping timeout: 268 seconds) |
| 01:40:30 | *** | Saving seen data "./dancer.seen" |
| 01:43:00 | | Quit lebellium (Quit: ChatZilla 0.9.90 [Firefox 22.0/20130612084701]) |
| 02:00 |
| 02:01:16 | | Quit liar (Quit: huiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii) |
| 02:02:57 | | Quit dfkt (Read error: Connection reset by peer) |
| 02:03:11 | | Join dfkt [0] (OxO29A@unaffiliated/dfkt) |
| 02:20:58 | | Quit soap (Remote host closed the connection) |
| 03:00 |
| 03:13:44 | | Join soap [0] (~soap@rockbox/staff/soap) |
| 03:15:06 | | Quit saratoga (Quit: Page closed) |
| 03:25:41 | | Quit krabador (Quit: Bah...) |
| 03:39:40 | | Join notben [0] (~ben@99-122-84-227.lightspeed.spfdmo.sbcglobal.net) |
| 03:40:32 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:06:27 | Ceninant | 500mb in 3 minutes..is that slow for USB 2.0? |
| 04:08:00 | | Join ikeboy [0] (~435622d3@www.haxx.se) |
| 04:25:46 | | Quit guymann (Ping timeout: 245 seconds) |
| 04:26:38 | | Join guymann [0] (~c@unaffiliated/guymann) |
| 04:27:44 | | Join amayer [0] (~amayer@h138.55.213.151.dynamic.ip.windstream.net) |
| 04:28:24 | ikeboy | Ceninant:It's slow for fullspeed usb 2.0, but probably not for most targets. 500MB is about 3MB/s, normal for mp3 player flash memory |
| 04:29:01 | ikeboy | On fullspeed usb 2.0 you'll get 60MB/s=10gb in3 min. What device are you using? |
| 04:41:43 | | Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) |
| 04:41:43 | | Quit amiconn (Disconnected by services) |
| 04:41:44 | | Quit pixelma (Disconnected by services) |
| 04:41:44 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
| 04:41:46 | | Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) |
| 04:41:47 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
| 04:47:56 | | Join TheSphinX_ [0] (~briehl@p5DD44EC8.dip0.t-ipconnect.de) |
| 04:49:41 | | Quit TheSphinX^ (Read error: Operation timed out) |
| 04:50:14 | | Join traps [0] (~dewlap@2001:5c0:1400:a::223) |
| 04:53:41 | | Quit kilroy (Ping timeout: 245 seconds) |
| 05:00 |
| 05:01:32 | | Quit ikeboy (Quit: CGI:IRC (EOF)) |
| 05:18:22 | | Quit alexbobp (Quit: leaving) |
| 05:18:31 | | Join alexbobp [0] (~alex@capitalthree.pwnz.org) |
| 05:31:07 | | Quit TheSeven (Disconnected by services) |
| 05:31:17 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
| 05:40:36 | *** | Saving seen data "./dancer.seen" |
| 05:51:23 | | Quit amayer (Quit: Leaving) |
| 06:00 |
| 06:01:54 | | Quit dfkt (Disconnected by services) |
| 06:01:56 | | Join dfkt_ [0] (dfkt@unaffiliated/dfkt) |
| 06:18:50 | | Quit notben (Quit: leaving) |
| 06:43:31 | | Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) |
| 06:56:53 | | Quit [Saint] (Remote host closed the connection) |
| 06:58:07 | | Join [Saint] [0] (~saint@rockbox/user/saint) |
| 07:00 |
| 07:11:42 | [Saint] | Hmmmmm... |
| 07:12:11 | [Saint] | Here's a question: If precut is applied, should we not alter the volume level displayed to the user? |
| 07:12:33 | [Saint] | should the volume level displayed not be "volume level + precut"? |
| 07:14:22 | [Saint] | for example, if you want line level, but have a preset with positive gain and precut applied, or are using precut as a volume cap. |
| 07:19:21 | [Saint] | It seems confusing, and non-obvious to me, that if I should apply a precut of -12dB (to cap the volume at line level on the Classic to avoid clipping when Ms [Saint] uses it without looking or allows dumbass workmates to use it even if they are looking) that the numeric volume displayed isn't inclusive of the precut value. it. "full volume" is still +12dB, even though it is *actually* 0dB. |
| 07:19:47 | [Saint] | s/value. it./value. ie./ |
| 07:40:40 | *** | Saving seen data "./dancer.seen" |
| 07:46:34 | | Quit amiconn (Remote host closed the connection) |
| 07:46:34 | | Quit pixelma (Remote host closed the connection) |
| 07:46:48 | | Join melmothX [0] (~melmoth@unaffiliated/melmothx) |
| 07:47:27 | | Join pixelma [0] (pixelma@rockbox/staff/pixelma) |
| 07:47:27 | | Join amiconn [0] (amiconn@rockbox/developer/amiconn) |
| 08:00 |
| 08:13:40 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:16:35 | | Quit kevku (Ping timeout: 245 seconds) |
| 08:37:10 | | Join LinusN [0] (~linus@giant.haxx.se) |
| 08:47:22 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 08:58:12 | | Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) |
| 09:00 |
| 09:05:25 | | Join Zagor [0] (~bjst@sestofw01.enea.se) |
| 09:05:25 | | Quit Zagor (Changing host) |
| 09:05:25 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
| 09:07:46 | | Join kevku [0] (~kevku@2a01:d0:ffff:34a::8:3) |
| 09:12:44 | | Join mortalis [0] (~kvirc@213.33.220.118) |
| 09:20:59 | | Quit GodEater (Changing host) |
| 09:20:59 | | Join GodEater [0] (~whoknows@rockbox/staff/GodEater) |
| 09:32:58 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 09:34:24 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 09:40:44 | *** | Saving seen data "./dancer.seen" |
| 09:54:16 | | Part LinusN |
| 10:00 |
| 10:06:44 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 10:09:43 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 10:10:56 | * | gevaerts grumbles |
| 10:11:08 | gevaerts | Full speed usb == 12 megabit/second |
| 10:13:27 | | Join mt` [0] (~quassel@rockbox/developer/mt) |
| 10:13:32 | copper | 08:03:49 UTC <ikeboy> On fullspeed usb 2.0 you'll get 60MB/s=10gb in3 min. What device are you using? |
| 10:13:51 | copper | I've never seen a USB2 device read or write at more than 30, maybe 35 MB/s |
| 10:13:56 | gevaerts | That too |
| 10:14:24 | copper | and I've bought some of those "ultra fast" USB flash drives |
| 10:14:29 | gevaerts | A full speed device still won't get more than about a megabyte :) |
| 10:14:41 | copper | 08:03:49 UTC <n1s> yeah, there's no portable encoder though |
| 10:15:04 | copper | TAK works with wine, and caudec (my command line transcoder) supports it too |
| 10:15:13 | copper | should work on OS X too |
| 10:15:28 | copper | it's perfectly usable on Linux |
| 10:15:44 | copper | now what's needed is playback support, really |
| 10:16:04 | copper | I consider that this is no longer a chicken and egg type of problem |
| 10:16:16 | | Quit mt (Ping timeout: 240 seconds) |
| 10:17:00 | [Saint] | I don't think the fact that an encoder exists was in question. I understood what was wanted was a portable encoder, for use as a recording option. |
| 10:18:19 | copper | oh |
| 10:19:56 | copper | also, I shouldn't copy paste timestamps when they're wrong :P |
| 10:25:33 | copper | http://outpost.fr/stuff/20130617101756.png |
| 10:25:37 | copper | transcoding flac to tak |
| 10:28:30 | Zagor | yuk, closed source |
| 10:29:45 | wodz | Zagor: have you had a chance to look why build system reports 'all green' ? |
| 10:30:00 | Zagor | no :-( |
| 10:36:00 | | Join kaputnik_ [0] (~kaputnik@port-92-206-81-126.dynamic.qsc.de) |
| 10:44:59 | | Join kaitsu1 [0] (~bubba@a91-152-170-133.elisa-laajakaista.fi) |
| 10:45:49 | | Part kaitsu1 |
| 10:46:36 | | Quit pamaury (Ping timeout: 256 seconds) |
| 10:50:17 | copper | TAK playback support in Rockbox would be pretty epic |
| 10:50:28 | copper | and maybe give TAK a boost in popularity |
| 10:50:46 | Zagor | I don't think TAK deserves a boost until they open the source |
| 10:50:51 | copper | now now |
| 10:51:01 | copper | don't be an extremist! |
| 10:51:39 | copper | anyway, does it not depend solely on a Rockbox developer wanting to do it? |
| 10:51:39 | Zagor | uh, I'm not. closed source is the extreme view. |
| 10:52:00 | copper | or will such commits be rejected? |
| 10:52:10 | Zagor | copper: yes it does. and I don't oppose it. I just personally don't think they deserve it yet. |
| 10:52:25 | copper | ok then |
| 10:53:29 | copper | from what I remember, the reverse engineered decoder in TAK is pretty short (in number of lines) |
| 10:53:49 | copper | er |
| 10:53:57 | copper | the reverse engineered TAK decoder in ffmpeg |
| 10:54:32 | copper | and I assume tagging is not an issue since Rockbox already supports APEv2 |
| 10:55:10 | copper | let's hope that saratoga will be able to do it |
| 10:55:16 | Zagor | perhaps I'm out of tune, but are people really prepared to optimise their entire music collection for rockbox? seeing that no other devices can play TAK even if we add it. |
| 10:55:28 | copper | meh |
| 10:55:31 | copper | you can't think like that |
| 10:55:48 | copper | everyone just needs to implement format X in their own software |
| 10:55:51 | Zagor | I just don't understand what it is that you like so much. |
| 10:56:00 | Zagor | well they can't, since it's locked down... |
| 10:56:12 | copper | they can now that there is a decoder |
| 10:56:20 | copper | open source decoder* |
| 10:56:33 | Zagor | there is only a reverse-engineered decoder. it could break anytime. |
| 10:56:53 | copper | it's been more or less approved by TAK's author, and he even offered to help |
| 10:57:07 | Zagor | I would personally really think twice before many hours adding support for a format that obviously don't want us to support it |
| 10:57:18 | copper | he does |
| 10:57:29 | copper | he's just very protective of his baby |
| 10:57:32 | Zagor | then he should release it |
| 10:57:46 | Zagor | it will NEVER take off as closed source |
| 10:57:50 | copper | it's been debated to death (with him) on HA, not gonna happen any time soon, unfortunately |
| 10:58:10 | Zagor | that's his choice. and my choice is to therefore ignore him. |
| 10:58:12 | copper | but he does have backwards compatibility in mind |
| 10:58:21 | wodz | Thats braindamaged thinking, sorry. |
| 10:58:47 | copper | he's actually a very nice guy |
| 10:59:09 | Zagor | I bet. but his code is 100% uninteresting to me in closed form. |
| 10:59:10 | copper | I don't agree with his decisions either |
| 10:59:29 | wodz | I am against investing limited developers time into some esoteric format without source. But if someone wants to - it is his choice |
| 10:59:48 | copper | fair enough |
| 11:00 |
| 11:13:10 | | Join LinusN [0] (~linus@giant.haxx.se) |
| 11:17:23 | [Saint] | I don't actually see what it would bring to the table. To be honest. |
| 11:17:45 | [Saint] | A lossless format with /slightly/ better compression, and worse performance than anything else we support. |
| 11:17:50 | [Saint] | ...yay? :) |
| 11:18:14 | [Saint] | Add to that the fact that it is never going to be adopted widely, and, I think its largely wasted effort even discussing it. |
| 11:20:10 | copper | not so slightly |
| 11:20:15 | copper | also, why worse performance? |
| 11:20:54 | [Saint] | My understanding is that it is more CPU intensive than any of the other supported lossless formats. |
| 11:21:25 | copper | what? no |
| 11:21:27 | copper | not at all |
| 11:21:37 | copper | TAK decoding is more or less on par with FLAC decoding |
| 11:21:45 | copper | certainly nothing like APE decoding |
| 11:22:18 | copper | there's a reason that TAK has been hailed as the (technically) king of lossless formats |
| 11:22:19 | | Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
| 11:22:50 | [Saint] | Hahahaha...that's fairly rich. |
| 11:23:25 | [Saint] | Ok, I was mistaken about the performance, it seems...but "king of lossless" is a bit rich. |
| 11:24:02 | [Saint] | "King of lossless formats adopted by 7 people", perhaps :) |
| 11:25:15 | copper | that's why I said technically |
| 11:25:57 | [Saint] | The compression doesn't seem /that/ much better...unless there has been some drastic improvements lately. |
| 11:26:06 | [Saint] | ~4% or so |
| 11:26:57 | gevaerts | [Saint]: can't be worse performance than ape -5000 |
| 11:27:06 | [Saint] | Well, this is true. |
| 11:27:19 | | Quit mt` (Read error: Connection reset by peer) |
| 11:27:30 | gevaerts | Being worse than that is actually mathematically proven to be impossible I believe :) |
| 11:27:52 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 11:28:46 | Zagor | performance would very likely improve if he released it |
| 11:28:47 | [Saint] | TAKp5 appears to be roughly twice as costly on CPU time as flac8 |
| 11:29:06 | copper | you mean p4 |
| 11:29:27 | [Saint] | I actually don't, but, OK. |
| 11:29:42 | copper | there is no p5 |
| 11:30:44 | copper | and actually TAK -p4 is faster than FLAC -8 |
| 11:30:52 | [Saint] | Ah. Well. I guess I shouldn't be too surprised sourcing this from HA... ;) |
| 11:31:21 | copper | the max setting is -p4m |
| 11:31:38 | [Saint] | This chart lists p4m, perhaps a typo. |
| 11:31:47 | copper | ? |
| 11:31:52 | copper | p4m is correct |
| 11:32:01 | [Saint] | now *that* was a typo :) |
| 11:32:05 | [Saint] | *5m, even. |
| 11:32:10 | copper | FLAC -8: 222x |
| 11:32:15 | copper | TAK -p4: 328x |
| 11:32:21 | copper | TAK -p4m: 148x |
| 11:32:40 | [Saint] | flac1.2.1 -0 8.801.938.201 67,99% 233 315x 383 192x 180 409x 234 314x |
| 11:32:40 | [Saint] | flac1.2.1 -5 8.113.749.200 62,68% 453 162x 584 126x 194 379x 257 285x |
| 11:32:40 | [Saint] | flac1.2.1 -8 8.071.892.842 62,35% 1596 46x 1668 44x 204 359x 262 280x |
| 11:32:40 | DBUG | Enqueued KICK [Saint] |
| 11:32:40 | [Saint] | TAKp0 8.031.153.454 62,04% 262 280x 408 180x 251 293x 290 253x |
| 11:32:40 | [Saint] | TAKp2 7.821.652.842 60,42% 397 185x 542 135x 285 257x 311 236x |
| 11:32:40 | *** | Alert Mode level 1 |
| 11:32:40 | [Saint] | TAKp5m 7.722.405.330 59,65% 3097 24x 3149 23x 347 212x 380 193x |
| 11:32:44 | [Saint] | fuck. |
| 11:32:46 | copper | but the 'm' parameter is not very useful |
| 11:32:47 | [Saint] | whoops. |
| 11:32:58 | copper | the gains are very marginal |
| 11:33:19 | [Saint] | those are: Compressed Compression PT PRate GT GRate PT PRate GT GRate |
| 11:34:27 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 11:34:27 | * | gevaerts recommends #tak |
| 11:34:47 | [Saint] | Reasonably old, but, I sincerely doubt the performance has changed much in ...well, ever. |
| 11:35:03 | [Saint] | Nor do I have any reason to believe it will. |
| 11:36:28 | [Saint] | copper: are you *sure* 4m is the highest? |
| 11:36:32 | copper | yupo |
| 11:36:36 | copper | -o |
| 11:36:47 | [Saint] | I find many, many, many references to p5{e|m} |
| 11:36:53 | copper | -p# select encoder preset #: 0-4 (fastest to strongest, default is 2). |
| 11:37:00 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 11:37:01 | copper | maybe in an old version |
| 11:37:08 | [Saint] | perhaps. |
| 11:38:50 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 11:38:56 | [Saint] | Anyhoo, indeed. If someone wants to implement this, in a sensible fashion, I'm certain no one will stand in their way. But I doubt it would help to bolster the popularity of either project. |
| 11:40:46 | *** | Saving seen data "./dancer.seen" |
| 11:42:41 | *** | Alert Mode OFF |
| 11:55:05 | | Part LinusN |
| 12:00 |
| 12:04:14 | | Quit krabador (Quit: Bah...) |
| 12:08:38 | | Quit kevku (Ping timeout: 260 seconds) |
| 12:32:55 | | Join kevku [0] (~kevku@2a01:d0:ffff:34a::8:3) |
| 12:36:49 | | Quit Kohlrabi (Read error: Operation timed out) |
| 12:37:56 | | Join Kohlrabi [0] (~kohlrabi@kohlio.de) |
| 12:41:53 | | Quit [Saint] (Remote host closed the connection) |
| 12:43:00 | | Join [Saint] [0] (~saint@rockbox/user/saint) |
| 12:43:24 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 12:45:43 | | Quit fs-bluebot (Ping timeout: 252 seconds) |
| 12:46:29 | | Quit bluebrother^ (Ping timeout: 276 seconds) |
| 12:47:01 | | Join fs-bluebot [0] (~fs-bluebo@g231120015.adsl.alicedsl.de) |
| 12:47:35 | | Quit mt (Ping timeout: 256 seconds) |
| 12:48:00 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 12:50:54 | copper | <saratoga_> TAK is such a dead-simple but also really efficient lossless format we should think about porting the ffmpeg decoder |
| 12:51:14 | copper | it seems though that the ffmpeg decoder is a lot slower than the reference decoder (Takc.exe) |
| 12:52:20 | copper | The difference between the official FLAC and TAK decoders on a 74 min file is small (7.94s vs 9.96s), but with ffmpeg, it is rather large (9.3s vs 15.3s) (FLAC and TAK respectively) |
| 12:52:26 | | Join kingratface [0] (~r@ks3295081.kimsufi.com) |
| 12:52:38 | kingratface | Hey all |
| 12:52:49 | kingratface | I'm having a problem with my sansa clip+ |
| 12:53:21 | funman | copper: it would be nice to profile ffmpeg and see where the slow-down is. maybe that part is already rewritten efficiently in rockbox? |
| 12:53:46 | copper | I would have no idea on how to do that |
| 12:54:00 | kingratface | I get a sort of pause and shakey noise whenever I try play stuff |
| 12:54:18 | copper | kingratface: what format? |
| 12:54:35 | kingratface | mp3 atm, lemme try a flac file |
| 12:55:19 | kingratface | okay, it's only mp3 |
| 12:55:52 | kingratface | roughly half the audio is replaced by silence |
| 12:55:54 | copper | maybe your MP3 file is wonky. Did you encode it yourself? |
| 12:56:12 | kingratface | I've tried with multiple MP3s |
| 12:56:16 | funman | copper: on Windows, I have no idea |
| 12:56:16 | kingratface | and they work on the firmware |
| 12:56:29 | copper | funman: I run linux! |
| 12:56:32 | kingratface | the default firmware, I mean |
| 12:57:00 | funman | copper: then you can use perf |
| 12:58:06 | copper | what package is that part of? |
| 12:58:10 | kingratface | It could be a hardware thing |
| 12:58:21 | kingratface | the battery has been crappy recently |
| 12:58:25 | copper | kingratface: you didn't answer my question :) |
| 12:58:43 | funman | copper: linux-tools |
| 12:58:48 | kingratface | No, I didn't encode them myself |
| 12:58:58 | kingratface | They're all lame V0s I think |
| 13:00 |
| 13:00:00 | kingratface | I've tried using a dev build, still doesn't work |
| 13:00:17 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 13:01:13 | | Join linuxstb [0] (~linuxstb@unaffiliated/linuxstb) |
| 13:01:23 | kingratface | I can play the same file fine on the sandisk firmware, so surely it's a problem with RB |
| 13:01:41 | copper | funman: got it, what perf command should I run? |
| 13:01:49 | | Join Derp [0] (~Derp@bb220-255-20-66.singnet.com.sg) |
| 13:01:59 | kingratface | I've googled around a bit but can't find any fixes, someone seemed to be having a similar problem in 2011 but never got anywhere with it |
| 13:05:11 | funman | copper: no idea :) |
| 13:05:51 | copper | you want "trace"? |
| 13:06:10 | | Quit mt (Ping timeout: 245 seconds) |
| 13:06:11 | funman | i want nothing, just giving you suggestions |
| 13:06:27 | funman | profiling which functions take the most CPU time can be interesting |
| 13:06:43 | copper | meh, I have no idea how to use it |
| 13:07:00 | funman | https://perf.wiki.kernel.org/index.php/Tutorial |
| 13:07:54 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 13:08:36 | kingratface | I'm at work atm so have don't have long, does anyone have any idea how I could fix this? Otherwise I guess I'll just use the sandisk firmware for a while |
| 13:09:12 | | Quit mt (Read error: Connection reset by peer) |
| 13:09:23 | funman | without the file hard to tell |
| 13:09:43 | kingratface | Without what file? |
| 13:09:54 | copper | the wonky MP3 file |
| 13:09:59 | | Part linuxstb ("Leaving") |
| 13:10:02 | kingratface | There is no wonky MP3 file |
| 13:10:08 | kingratface | I've tried with multiple MP3s |
| 13:10:16 | kingratface | and they work fine on other audio players |
| 13:10:17 | copper | none of which you encoded yourself |
| 13:10:20 | copper | and got from shady sources |
| 13:10:32 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 13:10:39 | copper | encode one yourself with LAME and try that |
| 13:10:51 | kingratface | They're all decent What.CD rips |
| 13:11:04 | copper | many what.cd users are clueless |
| 13:11:26 | kingratface | dude, the encodes are fine |
| 13:11:35 | copper | can you upload one of those MP3s online? Dropbox or whatever |
| 13:11:48 | copper | one that you have tested and that produces the problem |
| 13:11:55 | kingratface | http://5.135.191.54/ |
| 13:12:02 | kingratface | take any MP3 from there |
| 13:12:10 | copper | no |
| 13:12:20 | copper | please tell me which one specifically that produces the problem |
| 13:12:33 | copper | one that you have actually tried |
| 13:12:39 | kingratface | I've tried with a ton of MP3s |
| 13:12:41 | kingratface | but fine, wait |
| 13:12:52 | kingratface | http://5.135.191.54/Tom%20Waits%20-%201983%20-%20Swordfishtrombones%20%28V0%29/02%20-%20Shore%20Leave.mp3 |
| 13:13:04 | funman | kingratface: well i tried a ton of MP3s as well and they worked for me |
| 13:13:19 | kingratface | I've been using rockbox for over a year on this thing |
| 13:13:29 | kingratface | My MP3s have worked fine until now |
| 13:14:01 | funman | after a rockbox upgrade? |
| 13:14:25 | kingratface | nope |
| 13:14:52 | kingratface | I switched to a dev build after I started getting the problem to see if that'd fix it |
| 13:15:05 | kingratface | but up until then I hadn't changed the install in months |
| 13:15:19 | | Quit kugel (Remote host closed the connection) |
| 13:15:25 | | Join kugel [0] (~kugel@141.45.176.104) |
| 13:15:25 | | Quit kugel (Changing host) |
| 13:15:25 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 13:16:54 | copper | kingratface: playing that file right now on my Clip+ |
| 13:17:06 | kingratface | does it work? |
| 13:17:10 | copper | for now |
| 13:17:14 | kingratface | okay, so great |
| 13:17:15 | copper | I'll let it play until the end |
| 13:17:20 | kingratface | it's not a problem with the file then |
| 13:17:27 | copper | file looks fine |
| 13:17:47 | copper | foobar2000 says it's fine too |
| 13:18:10 | copper | I'm using the latest Rockbox dev build for the Clip+ |
| 13:18:47 | kingratface | so I guess the hardware must be fucked up somehow |
| 13:19:44 | copper | upgrade to the latest dev build just in case |
| 13:20:53 | kingratface | I already have |
| 13:21:06 | copper | ok it played back fine until the end |
| 13:21:30 | | Join mt` [0] (~quassel@rockbox/developer/mt) |
| 13:21:56 | kingratface | it's running dafc359-130616 atm |
| 13:24:42 | | Quit mt (Ping timeout: 260 seconds) |
| 13:25:30 | kingratface | I reset the settings and it's still screwed up |
| 13:25:36 | kingratface | anyway, I've really gotta run |
| 13:25:41 | kingratface | thanks for the help |
| 13:25:50 | kingratface | I guess I'll just get a replacement |
| 13:25:57 | kingratface | the battery is this one is crap anyway |
| 13:25:59 | kingratface | cheers folks |
| 13:26:02 | copper | np |
| 13:26:03 | | Quit kingratface (Quit: leaving) |
| 13:39:29 | fs-bluebot | Build Server message: New build round started. Revision c1eafa1, 217 builds, 20 clients. |
| 13:40:48 | * | [Saint] cannot think of a hardware problem that only affects mp3 |
| 13:40:50 | *** | Saving seen data "./dancer.seen" |
| 13:41:13 | [Saint] | The fact the issue spontaneously occurred is also suspicious. |
| 13:41:23 | | Join gapan [0] (~gapan@79.103.58.62.dsl.dyn.forthnet.gr) |
| 13:41:28 | [Saint] | Perhaps SanDisk is more lenient with fs corruption then we? |
| 13:41:58 | gevaerts | Almost certainly |
| 13:42:09 | gevaerts | Our FAT implementation isn't very robust |
| 13:42:27 | [Saint] | I was going to ask him to check his filesystem, but I came in late. |
| 13:42:41 | [Saint] | I wouldn't be surprised if it was trashed. |
| 13:43:01 | * | pamaury wonders if we should warn the user when the FS is found to be corrupted |
| 13:43:25 | [Saint] | I brought that up once upon a time myself. |
| 13:43:36 | [Saint] | I think it would be a good idea. But no one thought of a sane way to do so. |
| 13:44:25 | [Saint] | Can someone give me some input on my question earlier regarding volume level and precut? |
| 13:44:46 | [Saint] | should we, or should we not, adjust the level displayed to include the precut level? |
| 13:45:29 | pamaury | yeah, online checking of file system consistency is not exactly easy if you don't have a lot of memory to waste. There are some obvious cases you could catch but it would need a lot of experiment to check if this is useful at all |
| 13:45:57 | [Saint] | [17:19:22] <[Saint]> It seems confusing, and non-obvious to me, that if I should apply a precut of -12dB (to cap the volume at line level on the Classic to avoid clipping when Ms [Saint] uses it without looking or allows dumbass workmates to use it even if they are looking) that the numeric volume displayed isn't inclusive of the precut value. it. "full volume" is still +12dB, even though it is *actually* 0dB. |
| 13:45:57 | fs-bluebot | Build Server message: Build round completed after 388 seconds. |
| 13:45:58 | fs-bluebot | Build Server message: Revision c1eafa1 result: All green |
| 13:48:45 | [Saint] | I had a look, and doing "volume+precut" when precut and EQ are enabled seems trivial. |
| 13:49:10 | [Saint] | The question I'm wanting to know the answer to, is "IS this a sane thing to do?" |
| 13:56:29 | | Join linuxstb [0] (~linuxstb@unaffiliated/linuxstb) |
| 14:00 |
| 14:17:48 | | Quit wodz (Quit: Leaving) |
| 14:21:21 | | Join linuxstb_ [0] (~linuxstb@unaffiliated/linuxstb) |
| 14:21:32 | | Join Cen1nant [0] (~ceninant@adsl-74-240-112-61.bhm.bellsouth.net) |
| 14:21:59 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
| 14:22:02 | | Join Derpina [0] (~Derp@bb220-255-20-66.singnet.com.sg) |
| 14:23:00 | | Quit linuxstb (Disconnected by services) |
| 14:23:04 | | Nick linuxstb_ is now known as linuxstb (~linuxstb@unaffiliated/linuxstb) |
| 14:23:12 | | Quit Derp (Read error: Connection reset by peer) |
| 14:23:33 | kugel | pamaury: how did you find the key(s)? |
| 14:23:44 | pamaury | brute force |
| 14:24:04 | | Quit JdGordon (Ping timeout: 264 seconds) |
| 14:24:05 | kugel | such a huge key? |
| 14:24:40 | | Quit Ceninant (Ping timeout: 264 seconds) |
| 14:24:45 | pamaury | yeah, it looks huge but it is generated from a much smaller one in reality. It's all implemented into imxtools/sbtools/sbtoelf if you want to see the details |
| 14:25:03 | kugel | how large is the real key? |
| 14:25:20 | | Join JdGordon [0] (~jonno@101.174.205.167) |
| 14:25:21 | | Quit JdGordon (Changing host) |
| 14:25:21 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 14:26:14 | pamaury | let me check... |
| 14:26:26 | funman | for(int i = 0; i < 0x10000; i++) |
| 14:26:30 | funman | 16 bits? |
| 14:27:35 | pamaury | 48 bits |
| 14:27:52 | pamaury | laserfuse[0] and lower 16-bits of laserfuse[1] |
| 14:28:11 | pamaury | but in the two cases where I already brute forced the key, laserfuse[0] was 0 |
| 14:28:28 | pamaury | so it was really a 16-bit search... |
| 14:30:03 | kugel | hehe |
| 14:30:08 | pamaury | actually this is not exact: on device, the three "laserfuse" are used but what really matters is laserfuse[0] | laserfuse[1] so having two fuses for it is just security illusion |
| 14:30:53 | pamaury | same for laserfuse[2]: the whole content matters but you quickly realise it only has 65536 interesting values, they really screw up |
| 14:34:57 | funman | pamaury: how much time do you think you spent on this? |
| 14:35:23 | funman | so we can estimate a bruteforce speed in bits per hour (for the first key you found because i guess next ones are 'free') |
| 14:35:59 | pamaury | on what exactly ? |
| 14:36:50 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 14:37:03 | funman | on finding the key? |
| 14:37:20 | pamaury | with the tool it's instant |
| 14:37:29 | funman | well on writing the tools if you prefer |
| 14:38:51 | | Quit mt` (Ping timeout: 245 seconds) |
| 14:38:56 | pamaury | ah...hum, much longer ;) I spent many hours reversing the stmp tool to understand the format, then I had to spent like 10 hours of brute force to find the first key, then I disassembled the ROM and then I realise the key was smaller than expected |
| 14:50:59 | pamaury | I should time my reverse engineering sessions, that would depressing though |
| 14:51:39 | funman | pamaury: well for me too, that's why i do not count |
| 14:51:57 | funman | i guess it's still less than 2^1024 seconds though |
| 14:54:29 | Derpina | hey saint, im back! how else can i speak to you other than on IRC? i dont think i'll have IRC when booting into linux and H need instructions from you on the steps. Googletalk/whatsapp/facebook/ whatever? |
| 14:59:39 | | Join Derp [0] (~Derp@bb220-255-20-66.singnet.com.sg) |
| 14:59:41 | | Quit Derpina (Read error: Connection reset by peer) |
| 15:00 |
| 15:25:42 | | Quit mt (Read error: Connection reset by peer) |
| 15:25:45 | | Quit GeekShadow (Quit: leaving) |
| 15:26:19 | | Join GeekShadow [0] (~antoine@nzf.turmel.info) |
| 15:26:19 | | Quit GeekShadow (Changing host) |
| 15:26:19 | | Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow) |
| 15:27:12 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 15:29:20 | Derp | is anyone here at all? |
| 15:29:36 | copper | Nope. |
| 15:31:10 | | Quit kevku (Ping timeout: 245 seconds) |
| 15:37:39 | | Join mt` [0] (~quassel@rockbox/developer/mt) |
| 15:39:23 | | Quit mt (Ping timeout: 276 seconds) |
| 15:40:54 | *** | Saving seen data "./dancer.seen" |
| 15:44:35 | | Quit mortalis (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) |
| 15:46:44 | | Quit mt` (Read error: Connection reset by peer) |
| 15:50:38 | | Join Derpina [0] (~Derp@bb220-255-20-66.singnet.com.sg) |
| 15:50:39 | | Quit Derp (Read error: Connection reset by peer) |
| 15:51:10 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 15:53:10 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 15:55:12 | | Quit Derpina (Read error: Connection reset by peer) |
| 15:55:23 | | Join Derp [0] (~Derp@bb220-255-20-66.singnet.com.sg) |
| 15:59:26 | | Quit mt (Ping timeout: 240 seconds) |
| 16:00 |
| 16:08:11 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 16:11:18 | | Join wodz [0] (~wodz@89-75-41-78.dynamic.chello.pl) |
| 16:11:44 | wodz | http://forums.rockbox.org/index.php/topic,43157.msg219567/topicseen.html#msg219567 <- Thats quite interesting. Maybe worth to include in official build? |
| 16:16:37 | | Quit wodz (Quit: Leaving) |
| 16:22:54 | | Quit krabador (Quit: Bah...) |
| 16:25:39 | | Join madcat1990 [0] (~madcat199@216.185.65.74) |
| 16:27:06 | | Quit Derp () |
| 16:52:13 | | Join ikeboy [0] (~435622d3@www.haxx.se) |
| 16:53:34 | ikeboy | For the record http://en.wikipedia.org/wiki/Universal_Serial_Bus#USB_2.0_.28High_Speed.29 the usb 2.0 spec allows up to 480MBit/s which is 60MB/s |
| 16:53:51 | | Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) |
| 16:55:23 | copper | ikeboy: I don't know the specifics, but does that account for overhead? |
| 16:55:46 | copper | and again, I've never seen any real world device go that fast, including "super fast" expensive USB flash drives |
| 16:56:17 | copper | ikeboy: is that protocol speed or data speed? |
| 16:57:30 | ikeboy | Just because no one has made a "fullspeed" usb 2.0 doesn't mean that isn't fullspeed |
| 16:57:52 | copper | why were you talking about this again? |
| 16:58:26 | ikeboy | someone asked whether 500MB in 3 min was slow for usb 2.0 |
| 16:59:06 | copper | yup, pretty slow for USB2, but normal for internal flash and microsdhc cards |
| 16:59:39 | copper | er |
| 16:59:47 | copper | ikeboy: from your own wikipedia link: "USB 2.0: Released in April 2000. Added higher maximum signaling rate of 480 Mbit/s (effective throughput up to 35 MB/s or 280 Mbit/s)" |
| 16:59:56 | copper | "effective throughput up to 35 MB/s" |
| 17:00 |
| 17:00:06 | copper | which is precisely what I said |
| 17:00:28 | copper | and again it's not "full speed" it's "high speed" |
| 17:00:38 | copper | "hi-speed" |
| 17:01:14 | copper | so yeah 480 Mbps is the protocol speed, not the actual data throughput |
| 17:01:23 | copper | seems like there's quite a bit of overhead |
| 17:01:36 | | Join mt` [0] (~quassel@rockbox/developer/mt) |
| 17:01:40 | gevaerts | ikeboy: 60MB/s raw bitrate is *far* from actual speed |
| 17:02:36 | gevaerts | There are actually some tables in the USB spec about theoretically achievable packet rates IIRC, but that's still before UMS |
| 17:03:19 | | Quit Zagor (Quit: Clint excited) |
| 17:03:31 | madcat1990 | Too bad we don't have the documentation for every device, it'd make USB So much better.. |
| 17:03:58 | madcat1990 | Though, considering, the only problem I've ever had with RockBox's USB on my Mini2G was bad cables that made it act weird |
| 17:04:16 | | Quit mt (Ping timeout: 256 seconds) |
| 17:04:24 | copper | I'm waiting for more testing before I can report that I fixed my Fuze+ USB problems |
| 17:04:36 | gevaerts | Someone worked this out. High speed USB gives you a maximum of 53248000 bytes per second, but that's before you've counted the SCSI layer |
| 17:05:14 | gevaerts | So yes, I'd expect that 35 MB/s to be a more or less realistic maximum |
| 17:05:48 | gevaerts | (which is still twice as fast as the fastest disk I've ever heard of in a rockbox context) |
| 17:08:32 | copper | my iPod Classic does 22MB/s |
| 17:09:50 | gevaerts | Not bad! |
| 17:09:54 | copper | indeed |
| 17:10:46 | ikeboy | http://www.guruht.com/2009/11/usb-30-vs-usb-20-read-write-benchmarks.html says Theoretical Bandwidth iafter overhead 48MB/s but tested is 25/35 |
| 17:11:53 | copper | I wonder how fast the flash-based iPods go |
| 17:13:40 | ikeboy | http://www.usbflashspeed.com/42750 seems to be their fastest usb 2.0 drive benchmarked at 30MB/s |
| 17:14:41 | copper | ikeboy: well let me try my USB 3 HDD on a USB2 port |
| 17:15:06 | gevaerts | copper: there's some old data on http://www.rockbox.org/wiki/DiskSpeed |
| 17:15:14 | copper | it reads at over 50MB/s on USB3 |
| 17:15:50 | gevaerts | On a typical DAP you're not going to get anywhere near those speeds |
| 17:16:17 | gevaerts | Especially flash ones. They just don't *need* very fast flash, and faster == more expensive |
| 17:16:24 | pamaury | I think 48MB/s is theoretical raw performance, but on top of that you need to add UMS and SCSI which are not exactly light protocol. I would be interesting to do the exactly calculation |
| 17:16:42 | copper | 536870912 bytes (537 MB) copied, 15.772 s, 34.0 MB/s |
| 17:18:40 | | Quit lebellium (Remote host closed the connection) |
| 17:18:40 | gevaerts | pamaury: I think the actual protocol overhead strictly speaking isn't too bad. A header every 64K, and one packet for the request, so let's say two 512 byte packets extra per 64K, i.e. about 3% |
| 17:19:09 | gevaerts | What kills you is lack of queueing |
| 17:19:33 | | Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
| 17:19:47 | gevaerts | You can work around that up to a point with clever caching, but it's not magic |
| 17:20:06 | pamaury | yeah by protocol I mean: first send all data, then do all read/write, then send back status. So indeed so queuing means you cannot interleave as much as possible |
| 17:20:40 | gevaerts | I wouldn't be surprised if you could approach those 53248000 bytes per second using several devices |
| 17:21:00 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 17:21:27 | pamaury | yeah, let's plug 10 hard disk on the same link at next devcon !! :) |
| 17:22:16 | gevaerts | For PP502x (the one I know most about), you won't get more than about 15MB/s whatever you do. That's what I could get using throwaway transfers, where you just have to reply and not care about the data at all |
| 17:24:51 | gevaerts | By the way, if you want to test pure USB performance, don't use the ramdisk code in usb_storage.c. That's slower than a hard drive using DMA on some devices :) |
| 17:27:12 | n1s | haha |
| 17:29:14 | ikeboy | The person who asked the original question didn't mention he was using a rockbox target or even a mp3 player:) for all we know, he could have had a usb 2.0 hard drive |
| 17:29:35 | ikeboy | Ceninant500mb in 3 minutes..is that slow for USB 2.0? |
| 17:31:02 | ikeboy | And when i said fullspeed I didn't mean the technical definition I mean the fastest theoretically possible |
| 17:31:48 | copper | don't use "full speed" in the context of USB, since that's an actual standard name |
| 17:32:01 | copper | USB names suck, I'll give you that |
| 17:32:08 | gevaerts | They could have done better |
| 17:32:15 | copper | "full speed", "high speed", "super speed" |
| 17:32:22 | gevaerts | Also, don't call it "USB 2.0 speed" |
| 17:32:31 | copper | ah? why not? |
| 17:32:34 | gevaerts | Because low speed and full speed are valid USB 2.0 speeds |
| 17:32:42 | copper | hmmm |
| 17:32:55 | copper | what's next though |
| 17:32:57 | gevaerts | USB 3 is different for that, they refer to the USB 2 spec for anything non-superspeed |
| 17:32:59 | copper | "mega speed"? :P |
| 17:33:12 | gevaerts | So you *can* say "USB 3" meaning superspeefd |
| 17:35:54 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 17:39:15 | | Quit ikeboy (Quit: CGI:IRC) |
| 17:39:38 | | Quit mt` (Ping timeout: 276 seconds) |
| 17:40:58 | *** | Saving seen data "./dancer.seen" |
| 17:55:52 | | Quit mt (Read error: Connection reset by peer) |
| 17:57:14 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 18:00 |
| 18:00:35 | | Join johnlocke [0] (dcff014d@gateway/web/freenode/ip.220.255.1.77) |
| 18:00:47 | johnlocke | i need help with my clip+ |
| 18:00:52 | johnlocke | is anyone out there? |
| 18:00:54 | johnlocke | SOS! |
| 18:01:01 | evilnick | Don't ask to ask, just ask |
| 18:01:13 | evilnick | If someone here can help, then they will |
| 18:01:29 | johnlocke | i was following the guide at http://www.rockbox.org/wiki/SansaAMSUnbrick |
| 18:01:45 | johnlocke | up till the step with sudo fdisk -l |
| 18:02:22 | johnlocke | and only got a disk with no partition at 4MB capacity instead of the 979.75MB |
| 18:02:39 | johnlocke | am i doing something wrong? |
| 18:03:14 | evilnick | What OS are you using? Did you follow the steps after the instructions? |
| 18:03:25 | evilnick | "If it doesn't works, try to repeat it several times." |
| 18:03:28 | johnlocke | linux |
| 18:03:31 | johnlocke | Disk /dev/sdc: 4 MB, 4231680 bytes 1 heads, 9 sectors/track, 918 cylinders, total 8265 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xfffbfffd |
| 18:03:57 | evilnick | "You must make sure that the player was off before plugging the USB cable to the PC." |
| 18:04:00 | johnlocke | tried more than 10, still the same |
| 18:04:30 | johnlocke | "If it doesn't works, try to repeat it several times." by "it doesn't works", does he actually mean the situation im in or something else? |
| 18:04:39 | johnlocke | i disconnected the battery |
| 18:04:50 | evilnick | My guess is "anything that isn't exactly as described" |
| 18:05:13 | johnlocke | well thats helpful |
| 18:05:22 | evilnick | Thanks! |
| 18:05:30 | johnlocke | welcome |
| 18:07:07 | johnlocke | anyone else? |
| 18:13:09 | copper | how do you guys brick the clip+? |
| 18:13:39 | copper | USB problems? |
| 18:16:27 | johnlocke | check this |
| 18:16:28 | johnlocke | http://forums.rockbox.org/index.php?topic=24992.20 |
| 18:17:27 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 18:20:37 | johnlocke | its funny how theres a long list of people in this channel but no ones talking |
| 18:20:54 | Torne | no, it's entirely normal |
| 18:24:35 | johnlocke | normal, but still funny |
| 18:24:51 | copper | I can't stop laughing |
| 18:25:57 | copper | I wonder how much (if at all) bad quality microsdhc cards affect Rockbox functionning properly |
| 18:26:22 | copper | that sentence doesn't sound right… |
| 18:28:01 | copper | any chance that Rockbox can miss some special case errors from the reader and go wonky because of it? |
| 18:29:01 | johnlocke | i got a feeling the problems im having are related to storage issues since it was pluged in the the PC for file transfer just before it went wonky, then dead |
| 18:32:52 | | Quit melmothX (Ping timeout: 240 seconds) |
| 18:34:53 | johnlocke | if anyone is looking, should i just short the pins in red or the ones in blue as well? |
| 18:34:53 | johnlocke | http://www.rockbox.org/wiki/pub/Main/SansaAMSUnbrick/sandisksansaclipplusdis.jpg |
| 18:35:04 | | Join melmothX [0] (~melmoth@unaffiliated/melmothx) |
| 18:35:46 | copper | sounds hardcore |
| 18:38:11 | johnlocke | do you know stuff? |
| 18:38:31 | copper | not really |
| 18:39:51 | | Join Strife89 [0] (~Strife89@2602:306:250e:8d79:225:d3ff:fed6:15a) |
| 18:41:33 | | Join mt` [0] (~quassel@rockbox/developer/mt) |
| 18:43:22 | | Quit dfkt_ (Remote host closed the connection) |
| 18:44:06 | | Quit mt (Ping timeout: 246 seconds) |
| 18:45:00 | | Quit johnlocke (Quit: Page closed) |
| 18:59:59 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 19:00 |
| 19:00:32 | | Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) |
| 19:05:27 | | Quit Zarggg (Quit: Zarggg) |
| 19:06:18 | | Join Zarggg [0] (~zarggg@24.229.140.62.res-cmts.sm.ptd.net) |
| 19:08:45 | | Quit scorche|sh (Changing host) |
| 19:08:45 | | Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) |
| 19:22:42 | | Nick Gareth__ is now known as Gareth (~gareth@2607:ff38:2:83::3) |
| 19:30:20 | | Join mt [0] (~quassel@rockbox/developer/mt) |
| 19:32:45 | | Quit mt` (Ping timeout: 246 seconds) |
| 19:41:01 | *** | Saving seen data "./dancer.seen" |
| 19:48:43 | | Quit thomasjfox (Quit: Konversation terminated!) |
| 19:59:58 | | Quit pamaury (Ping timeout: 268 seconds) |
| 20:00 |
| 20:00:00 | | Join Epicanis [0] (~Epicanis@static-72-95-113-7.port.east.myfairpoint.net) |
| 20:09:46 | | Quit kevku (Ping timeout: 260 seconds) |
| 20:11:00 | | Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) |
| 20:28:13 | | Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) |
| 20:33:26 | | Quit mt (Ping timeout: 245 seconds) |
| 20:43:44 | | Join kaputnik__ [0] (~kaputnik@port-92-206-102-83.dynamic.qsc.de) |
| 20:47:06 | | Quit kaputnik_ (Ping timeout: 260 seconds) |
| 20:58:52 | | Quit simabeis_ (Ping timeout: 264 seconds) |
| 20:59:15 | | Quit Strife89 (Quit: Vamoose.) |
| 21:00 |
| 21:00:19 | | Quit Belzebub (Ping timeout: 248 seconds) |
| 21:04:57 | | Join simabeis [0] (~simabeis@lobmenschen.de) |
| 21:07:26 | | Join einhirn [0] (~Miranda@p4FF89E64.dip0.t-ipconnect.de) |
| 21:08:00 | | Join Belzebub [0] (torrentow@gateway/shell/sundance.i-rpg.net/x-gprngthrgifuakwb) |
| 21:11:51 | | Quit einhirn (Ping timeout: 240 seconds) |
| 21:14:58 | | Join saratoga [0] (123e1cf8@gateway/web/freenode/ip.18.62.28.248) |
| 21:15:43 | saratoga | copper: the ffmpeg flac decoder is *really* fast though, so 50% slower then it is still very fast |
| 21:15:58 | saratoga | probably the official TAK decoder uses more SSE stuff on windows |
| 21:19:55 | saratoga | being closed source is annoying, and I told the developer a couple years ago that he'd either open source it himself or have it reverse engineered, but he didn't listen and here we are :) |
| 21:22:16 | | Quit akaWolf (Ping timeout: 264 seconds) |
| 21:41:04 | *** | Saving seen data "./dancer.seen" |
| 21:41:51 | copper | saratoga: #rockbox-community doesn't share your enthusiasm about any of it |
| 21:42:12 | copper | and they also blame the decoding speed |
| 21:43:19 | gevaerts | copper: please go and misrepresent other people's opinions somewhere else |
| 21:43:47 | copper | what? |
| 21:43:58 | copper | how was that not accurate? |
| 21:44:41 | copper | saratoga replied to my assessment of the ffmpeg decoding speed |
| 21:44:51 | copper | hence the relevance |
| 21:45:22 | copper | oh screw it |
| 21:47:54 | saratoga | its tough to generalize the performance on x86 devices to that on ARM, but given the relative numbers to flac and that the format seems algorithmically similar, I expect decode performance to be quite good |
| 21:48:18 | | Quit thomasjfox (Quit: Konversation terminated!) |
| 21:55:09 | | Quit kaputnik__ (Ping timeout: 252 seconds) |
| 22:00 |
| 22:01:35 | | Quit krabador (Quit: Bah...) |
| 22:02:17 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 22:04:22 | | Quit krabador (Client Quit) |
| 22:06:11 | | Join stoffel [0] (~quassel@pD9E40173.dip0.t-ipconnect.de) |
| 22:09:34 | | Join kaputnik__ [0] (~kaputnik@port-92-206-102-83.dynamic.qsc.de) |
| 22:17:54 | | Quit b1101 (Quit: b1101) |
| 22:21:16 | copper | saratoga: I guess that would require more work than just porting the decoder |
| 22:21:37 | copper | optimizations I mean |
| 22:21:39 | saratoga | generally decoders need a lot of optimization to work well on portable systems |
| 22:41:44 | | Join MethoS- [0] (~clemens@galileo-506.wohnheim.uni-bremen.de) |
| 22:51:38 | | Join dfkt [0] (OxO29A@unaffiliated/dfkt) |
| 22:56:06 | | Join TheLemonMan [0] (~LemonBoy@unaffiliated/thelemonman) |
| 23:00 |
| 23:04:37 | | Quit n1s (Quit: Ex-Chat) |
| 23:08:01 | | Quit kevku (Ping timeout: 260 seconds) |
| 23:09:40 | | Quit stoffel (Remote host closed the connection) |
| 23:22:41 | | Quit MethoS- (Read error: Connection reset by peer) |
| 23:23:23 | | Join MethoS- [0] (~clemens@galileo-506.wohnheim.uni-bremen.de) |
| 23:28:00 | | Quit melmothX (Quit: #) |
| 23:39:18 | | Quit Bagder (Changing host) |
| 23:39:18 | | Join Bagder [241] (~daniel@rockbox/developer/bagder) |
| 23:39:33 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 23:41:08 | *** | Saving seen data "./dancer.seen" |
| 23:44:03 | | Quit shamus (Read error: Connection reset by peer) |
| 23:45:03 | | Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) |
| 23:49:29 | | Quit Scall (Ping timeout: 245 seconds) |
| 23:50:57 | | Join Scall [0] (~chat@unaffiliated/scall) |
icon identifies that the person is a core developer (has commit access).