--- Log for 17.06.113  Server: leguin.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 7 days and 14 hours ago

00.29.33 #       <fs-bluebot> Build Server message: 3New 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: 3Build round completed after 349 seconds.
00.35.22 #       <fs-bluebot> Build Server message: 3Revision 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.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.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.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.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.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.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.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.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.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.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.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.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.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: 3New 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: 3Build round completed after 388 seconds.
13.45.58 #       <fs-bluebot> Build Server message: 3Revision 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.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.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.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.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> Ceninant	500mb 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.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.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.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.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.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.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)