00:00:29 | preglow | !!! |
00:00:30 | preglow | haha |
00:00:34 | crashd | or |
00:00:37 | crashd | 200 dolllars |
00:00:38 | preglow | porting musepack wouldn't be hard with an arm... |
00:01:05 | Bagder | I guess ipod qualifies as an arm based player |
00:05:27 | preglow | it has to be 1) programmable, 2) non-ipod |
00:05:38 | Bagder | hehe |
00:05:55 | t0mas | preglow: why not iriver H3xx ? |
00:05:59 | preglow | i'm tired of everybody having ipod |
00:06:01 | t0mas | or the new archos things? |
00:06:03 | preglow | t0mas: that's coldfire based |
00:06:03 | t0mas | with video? |
00:06:14 | t0mas | preglow: jup, but why the arm thing? |
00:06:21 | t0mas | rockbox won't run on it for some months... |
00:06:22 | crashd | preglow: h10 h10! |
00:06:28 | preglow | i wanna learn arm asm :PP |
00:07:09 | t0mas | lol |
00:13:44 | | Join Road_Runner [0] (~55416801@labb.contactor.se) |
00:14:30 | Road_Runner | Hey. Question: how can you delete the playlist that is now playing? I mean, starting from fresh ? |
00:16:34 | preglow | have you tried reading the manual? |
00:16:39 | Road_Runner | ho yeah. |
00:17:15 | Road_Runner | talks about insert & queue. |
00:17:29 | Road_Runner | sometimes I can get it but i'm not sure how. |
00:18:57 | Road_Runner | I would expect the 'playlist options' screen would have a function for clearing the o.t.f. playlist, but I guess the problem starts because there isn't an o.t.f. playlist. |
00:22:41 | Road_Runner | any1? |
00:25:15 | | Quit tvelocity () |
00:26:57 | | Quit markun () |
00:31:37 | | Quit Harpy (Read error: 110 (Connection timed out)) |
00:32:44 | Road_Runner | 1 way I found to have a fresh playlist is to play the last file on the playlist & then removing it from list - > "END OF SONG LIST" - > list is empty |
00:33:02 | Road_Runner | but isn't there a better way? |
00:35:29 | Road_Runner | :((((((((((((((((((((((((((((((((((( |
00:39:21 | preglow | no idea |
00:41:46 | Road_Runner | don't you use playlist or what..? |
00:47:23 | preglow | i do |
00:47:30 | preglow | but i haven't really been using rockbox for long |
00:47:50 | preglow | i'm mostly just queueing stuff |
00:51:39 | Road_Runner | argh |
00:54:42 | | Join courtc_ [0] (~courtc@adsl-158-35-74.asm.bellsouth.net) |
00:55:32 | | Quit courtc (Read error: 110 (Connection timed out)) |
00:56:46 | preglow | oh well |
00:56:47 | preglow | gnight |
00:56:51 | | Quit preglow ("vel") |
00:57:01 | | Join bg_ [0] (~chatzilla@c24.241.230.113.mad.wi.charter.com) |
00:57:20 | Road_Runner | nighty night |
00:57:28 | Road_Runner | wOOps |
01:00 |
01:02:52 | | Quit bg_ ("Chatzilla 0.9.68.5 [Firefox 1.0.4/20050515]") |
01:04:38 | | Join hardeep [0] (hardeeps@SDF.LONESTAR.ORG) |
01:04:57 | | Part MoosCamaro |
01:11:17 | | Join Seedy [0] (ben@l192-117-115-168.broadband.actcom.net.il) |
01:12:35 | | Quit Seed (Nick collision from services.) |
01:13:36 | | Nick courtc_ is now known as courtc (~courtc@adsl-158-35-74.asm.bellsouth.net) |
01:34:50 | | Quit gromit` (Remote closed the connection) |
01:37:34 | *** | Saving seen data "./dancer.seen" |
01:43:31 | | Quit ShockerEngr (Read error: 145 (Connection timed out)) |
01:46:31 | | Quit Stryke` (Read error: 110 (Connection timed out)) |
01:47:48 | | Quit ]RowaN[ () |
02:00 |
02:25:48 | | Join ashridah [0] (ashridah@220-253-123-11.VIC.netspace.net.au) |
02:27:30 | | Quit Sucka ("a bird in the bush is worth two in your house") |
02:40:10 | | Quit hicks (Remote closed the connection) |
02:40:34 | [solid] | vorbis playback passed 10hrs and is still playing :) |
02:42:13 | Rori | "Something is afoot" replied the leg |
02:42:38 | Rori | [solid] tis a time to rejoice! |
02:43:39 | Rori | Now I need to rerip some of my collection to ogg or lame. shame most of my mp3 collection is in non-lame format :P |
02:43:52 | Rori | and I don't own the cd's to rerip them |
02:43:52 | [solid] | i need to get some sleep ;o |
02:44:38 | [solid] | g'night |
02:45:03 | Rori | how will you know when it stops playing? |
02:46:21 | yngwi | it won't :-) |
03:00 |
03:33:25 | | Join amiconn_ [0] (~jens@p54BD54A6.dip.t-dialin.net) |
03:37:35 | *** | Saving seen data "./dancer.seen" |
03:47:36 | | Quit yngwi ("Chatzilla 0.9.68a [Firefox 1.0.4/20050511]") |
03:51:44 | | Quit amiconn (Read error: 110 (Connection timed out)) |
03:51:45 | | Nick amiconn_ is now known as amiconn (~jens@p54BD54A6.dip.t-dialin.net) |
03:53:31 | | Quit Rori (Read error: 104 (Connection reset by peer)) |
03:56:07 | | Join Rori [0] (MO-Pantsu@deadman3000.plus.com) |
03:56:28 | Rori | pc crashed during Rockbox disk to disk copy :P |
03:58:48 | | Quit Road_Runner ("CGI:IRC (EOF)") |
04:00 |
04:00:20 | HCl | oh my fucking god gta san andreas is sweet |
04:00:42 | * | HCl stole a jet powered plane from the airport and stored it in his personal hangar |
04:01:38 | * | HCl sleeps |
04:05:43 | | Join QT_ [0] (as@area51.users.madwifi) |
04:13:12 | Rori | I don't get this. I was playing a track and 2/3 through it stops but the time still says the song has not finished and suddenly it starts playing back a track from a different folder that I had not playlisted or anything |
04:13:34 | Rori | weird bug |
04:17:34 | | Quit QT (Read error: 113 (No route to host)) |
04:21:42 | Rori | does anyone know what version of Lame -nogap was introduced? |
04:33:00 | Rori | gapless on lame does not seem to work |
04:43:13 | | Join asdsd____ [0] (~asdsd@h-67-100-29-141.miatflad.dynamic.covad.net) |
04:47:57 | | Part asdsd____ |
05:00 |
05:02:04 | | Join barbita [0] (~oozz19045@host2.bellsouth.com.ec) |
05:06:34 | | Part barbita |
05:15:12 | Rori | hmmm. seems it may be the way people rip and encode in lame perhaps? trying my own rip in EAC with the −−nopgap option |
05:15:27 | Rori | −−nogap rather |
05:16:20 | Rori | I hear conflicting stuff about how it should be done. some say you should do −−nogap track1.wav track2.wav track3.wav in one command while others state this is false information |
05:19:29 | | Join david88 [0] (davidd@67-50-86-124.br1.tbr.ga.frontiernet.net) |
05:20:52 | | Quit david88 (Client Quit) |
05:22:43 | Rori | −−nogap appears to be broken in eac |
05:34:26 | crwl | using −−nogap with all the decoded wavs at the same command line is quite difficult, i don't know of any ripper/encoder tools that support it natively |
05:35:11 | crwl | i thought that "gapless support with lame tag information" means something like that lame writes the exact samples that need to be decoded in a header and a decoder that supports the header, can play those files gaplessly |
05:35:29 | crwl | and files encoded with −−nogap is something that any mp3 decoder can support |
05:36:21 | crwl | but i don't actually know :) |
05:36:31 | crwl | that's just what i'm *hoping* |
05:37:39 | *** | Saving seen data "./dancer.seen" |
05:41:08 | ashridah | crwl: the man page for lame here suggests that it should be given multiple contiguous files |
05:41:36 | ashridah | ie, it's only interested in doign gapless analysis for a single album, not from randomsong1 -> randomsong2 |
05:41:50 | crwl | yes |
05:41:58 | crwl | but that's pretty cumbersome |
05:42:27 | crwl | wouldn't storing the sample exact lenght of the source file somewhere be enough, as long as the decoder supports that+ |
05:42:49 | crwl | bah, the easiest way is to ditch lame and use vorbis all the way :P |
05:42:53 | crwl | work to do -> |
05:46:41 | | Quit hardeep ("BitchX: born to raise hell") |
05:48:38 | | Join DMJC [0] (~DMJC@60-240-161-237.tpgi.com.au) |
05:53:54 | Rori | winLame does |
05:54:34 | Rori | testing now |
05:55:00 | Rori | you rip with eac to wav then encode in winLame with the nogap option built in |
05:55:07 | Rori | need to tag afterwards though methinks |
06:00 |
06:02:36 | Rori | hmmm |
06:03:01 | Rori | it does not work. I think you are right. Ogg kills Lame for gapless. |
06:11:22 | DaKi][er | and in compression to quality ratio as well, but it would still be handy to have a true gapless for all mp3's that works for thoes that have their libaries of music already encoded this way |
06:13:25 | ashridah | can't squeeze blood from a stone |
06:26:59 | | Join mishter [0] (~chatzilla@dyn-123-055.res.aecom.yu.edu) |
06:28:25 | | Quit mishter (Client Quit) |
06:44:26 | | Join elinenbe_ [0] (trilluser@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
07:00 |
07:37:42 | *** | Saving seen data "./dancer.seen" |
07:45:43 | t0mas | morning:) |
08:00 |
08:05:12 | | Nick Seedy is now known as Seed (ben@l192-117-115-168.broadband.actcom.net.il) |
08:24:27 | | Join mrlala [0] (~mistame@cpe-66-75-129-164.san.res.rr.com) |
08:31:04 | | Quit ashridah (Read error: 60 (Operation timed out)) |
08:33:21 | | Join ashridah [0] (ashridah@220-253-121-11.VIC.netspace.net.au) |
08:41:01 | amiconn | morning |
08:45:58 | | Join scriptkitty [0] (~katerina@c-67-176-83-251.hsd1.co.comcast.net) |
08:48:39 | | Join gromit` [0] (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net) |
08:57:37 | | Quit DMJC ("Leaving") |
09:00 |
09:00:45 | | Part courtc ("Leaving") |
09:02:11 | | Quit mrlala (Read error: 110 (Connection timed out)) |
09:09:40 | | Join bobTHC [0] (~bobthc@l03m-36-170.d1.club-internet.fr) |
09:17:07 | | Join Harpy [0] (qkgkI4EyOZ@dsl-hkigw7wbb.dial.inet.fi) |
09:19:01 | | Join dapureplaya [0] (~anon@CPE-144-136-72-137.nsw.bigpond.net.au) |
09:19:43 | dapureplaya | hi everyone |
09:19:45 | dapureplaya | does Musepack playback yet? |
09:19:58 | bobTHC | mornin' folks ! |
09:20:06 | dapureplaya | good evening ;) |
09:20:13 | bobTHC | :) |
09:20:40 | * | Bagder waves |
09:20:52 | * | dapureplaya waves back |
09:23:54 | Bagder | the linux port threads on misticriver don't stop |
09:24:03 | Bagder | I love them ;-) |
09:24:18 | dapureplaya | heh |
09:27:37 | | Join StrathAFK [0] (~mike@dgvlwinas01pool0-a219.wi.tds.net) |
09:31:25 | linuxstb | dapureplaya: No, Musepack doesn't work yet. But it's getting closer. |
09:31:44 | dapureplaya | ah right just curious |
09:32:07 | dapureplaya | i wasn't sure coz i haven't been keeping up to date with CVS activity on the site. i thought i may have missed out on some news. |
09:32:12 | Bagder | we should keep a list of codecs and their status in the wiki... |
09:32:32 | linuxstb | There is one (I think it's at the end of SoundCodecs) |
09:32:51 | Bagder | aha |
09:32:59 | * | Bagder looks |
09:33:19 | dapureplaya | of course |
09:33:25 | dapureplaya | but i thought it wasn't updated. |
09:33:40 | dapureplaya | ie. Wavpack says it's not playable on iRiver yet hehe :-p |
09:34:20 | dapureplaya | but i guess MPC isn't "ready" yet. |
09:34:43 | linuxstb | I hadn't noticed that Wavpack commit. Anyone tested it? |
09:34:51 | dapureplaya | listening to it now |
09:35:05 | dapureplaya | lossy format at avg 500 kBit |
09:35:15 | dapureplaya | i'm going to try lossless format now |
09:35:20 | Bagder | cool |
09:35:42 | dapureplaya | runs very well. the hard drive doesn't get much of a workout |
09:35:45 | linuxstb | So should I add the tick for WavPack in the SoundCodecs page? |
09:35:54 | dapureplaya | for sure |
09:37:47 | *** | Saving seen data "./dancer.seen" |
09:38:11 | linuxstb | Well, that's 6 codecs supported (8 if you split MPEG into 1,2 and 3). Truely a Multi-Codec Jukebox. |
09:38:56 | Bagder | amazingly quick |
09:39:05 | dapureplaya | i would say that the codec status would be a bit more than 50% now :) |
09:39:35 | dapureplaya | you guys been progressing rapidly thruout the last 2 weeks. |
09:42:43 | Bagder | I'm only using rockbox these days |
09:43:01 | dapureplaya | yep. Same. Haven't used iRiver FW for a while. |
09:43:15 | dapureplaya | well since FLAC playback anywayz |
09:43:27 | | Join oxygen77 [0] (~c1c28427@labb.contactor.se) |
09:43:47 | linuxstb | I've never used the IRiver FW for more than about 10 minutes - I just couldn't understand it. |
09:44:19 | Bagder | hehe, I fully sympathize with that |
09:44:21 | dapureplaya | the gapless on lossy wavpack os flawless at the moment |
09:44:25 | dapureplaya | *is |
09:44:59 | linuxstb | dapureplaya: That doesn't surprise me - only MP3 is a problem to get gapless, everything else "Just works". |
09:45:39 | dapureplaya | yeah true. Hey wasn't there a commit recently to try and fix the MP3 gappless? how does it run now? haven't tried it |
09:45:50 | | Quit Strath (Read error: 110 (Connection timed out)) |
09:46:22 | linuxstb | It's still not working perfectly - but the code is written, it just needs debugging. |
09:47:14 | dapureplaya | ah. Hey, quick change of topic. i can't find the codec to encode AC3 files for dbPowerAmp. What can i use? Any tips? |
09:47:46 | | Quit oxygen77 (Client Quit) |
09:48:09 | linuxstb | The main purpose of AC3 was to allolw you to rip audio from DVDs (and some digital TV) and play it on the iRiver without re-encoding. |
09:49:14 | dapureplaya | oh i see. Is it a DVD-audio format? |
09:49:16 | linuxstb | "ffmpeg" comes with an AC3 encoder, but I don't know how that works with Windows. |
09:49:28 | linuxstb | Almost - it's an audio format for DVD-Video. |
09:49:44 | linuxstb | DVD-Audio uses either uncompressed PCM or "Meridian Lossless Packing". |
09:52:23 | dapureplaya | ah rightio |
09:53:02 | dapureplaya | are tehre any plans on implementing APE at the moment? |
09:53:03 | linuxstb | DVD-Audio is my other interest outside Rockbox - see my project at http://dvd-audio.sourceforge.net/ |
09:55:51 | dapureplaya | ah nvm i just foudn out APE isn't open source |
09:56:37 | linuxstb | And the other (possible) problem is that it has a reputation for being "hard" to decode - i.e. takes a lot of processor power. So I'm not sure it would even be possible. |
09:57:27 | DaKi][er | isnt much of a market out there for APE, it only advantage over FLAC is a few % better compression, but FLAC is far more popular |
09:58:16 | dapureplaya | ah i see. |
09:58:22 | linuxstb | I am quite interested in adding a Shorten decoder - now that there is a GPL'd decoder available. But it's a low priority, I convert all my SHNs to FLAC anyway. |
09:58:22 | dapureplaya | that's fair enough\ |
09:59:21 | dapureplaya | yeah never heard of shorten before until i came across rockbox |
09:59:51 | linuxstb | I think Ape could have become more popular if released under a different license - it started to gain momentum, but then stopped when no open source projects adopted it. |
10:00 |
10:00:09 | linuxstb | Or maybe it's simply the case that FLAC is good enough. |
10:00:23 | dapureplaya | much more popular aswell. |
10:00:26 | DaKi][er | and a bit more widely supported |
10:04:46 | | Join tvelocity [0] (~tony@ipa78.5.tellas.gr) |
10:05:17 | | Join rasher [0] (~3e4f4094@labb.contactor.se) |
10:08:38 | | Nick Lynx_awy is now known as Lynx_ (Lynx@134.95.189.59) |
10:08:54 | dapureplaya | linuxstb: your project is pretty clever. not a bad idea at all. |
10:13:25 | linuxstb | Thanks. It's working great for me. |
10:13:36 | dapureplaya | you working on it solo? |
10:13:51 | dapureplaya | or you got a team of minions on the case aswell? ;) |
10:13:59 | linuxstb | Yep. A couple of people have written "front-ends" (one Windows, one Mac), but dvda-author itself is just me. |
10:14:24 | linuxstb | No minions have shown any interest... |
10:14:42 | dapureplaya | hehe |
10:28:37 | | Quit tvelocity ("Leaving") |
10:30:49 | | Quit [solid] ("leaving") |
10:33:28 | | Join mrlala [0] (~mistame@cpe-66-75-129-164.san.res.rr.com) |
10:36:45 | | Quit dapureplaya (Read error: 145 (Connection timed out)) |
11:00 |
11:10:05 | | Quit mrlala ("-=SysReset 2.53=-") |
11:19:56 | | Join DMJC [0] (~DMJC@60-240-161-237.tpgi.com.au) |
11:27:27 | * | Bger is surprised of FLAC compressing 3CDs at average compression ratio 0.25 ... |
11:30:43 | ashridah | i expected flac encoding to be more cpu intensive when set to −−best |
11:31:21 | Bger | :) |
11:31:39 | ashridah | i'm also vaguely considering converting my mp3s to flac, even tho i don't have the originals. it's not like they're going to DEcrease in quality. |
11:31:52 | Bger | definitely |
11:31:59 | ashridah | hm. only problem is, that's a fairly large increase in size |
11:32:09 | ashridah | won't be able to keep as much pron on my player :) |
11:32:24 | Bger | but i don't think that you'll have any advantage of doing it |
11:32:59 | Bger | but 25% from the size of the original .wav .... |
11:33:08 | Bger | of |
11:33:21 | ze | why would you reencode from mp3 to flac? |
11:33:32 | ashridah | ze: elitism |
11:33:37 | ze | its dumbism |
11:33:41 | ashridah | why else :) |
11:34:04 | ze | nobody'll think you're elite for transcoding already lossy files into a bigger lossless format |
11:34:07 | ze | heh |
11:34:31 | ze | you've already lost the quality so the only effect of making them lossless now is to take up more space for no reason |
11:34:43 | ashridah | ah, you're misconstruing the context. i get to be elite when i tell them all my music is in flac, not how it got there :) |
11:34:52 | ze | heh |
11:35:12 | ashridah | ze: elitism has never been about having no flaws, it's about cleverly hiding them |
11:35:37 | ashridah | otherwise you wouldn't need it, since you'd have no ego problems to begin with |
11:35:42 | ze | heh |
11:35:58 | ashridah | the reality is, i really couldn't be fucked sitting through a marathon reencoding session |
11:36:01 | ze | what makes you think true elitism is about ego problems? |
11:36:21 | ze | thats more likely just the overt pseudoelitism |
11:36:42 | ze | thats nothing but ostensible elitism |
11:37:01 | ze | and says nothing about us underspoken elitists who're just better than most people but prefer not to go around bragging about it |
11:37:05 | ze | :p |
11:37:21 | * | ashridah shrugs |
11:37:31 | ze | ok there was supposed to be humor in that |
11:37:33 | ze | but nevermind |
11:37:36 | ashridah | you are your own biggest critic. |
11:37:43 | ashridah | oh, no, i got it |
11:37:48 | *** | Saving seen data "./dancer.seen" |
11:38:12 | ze | heh |
11:38:39 | ashridah | mp3's make me feel dirty, like i'm using gifs on a webpage or something |
11:38:45 | ze | well yeah you should always be your own biggest critic though |
11:38:58 | ze | but there's a distinct difference between what you know you're capable of and what you've manifested so far |
11:39:06 | ze | which is where your self critism comes from |
11:39:16 | ze | at least in some cases |
11:39:25 | ze | yeah i know what you mean |
11:40:17 | ze | my recomendation is to track down or otherwise obtain honest ogg and/or flac rips to replace them with though |
11:41:06 | ashridah | ze: my biggest problem is that i was robbed a few years back. i don't have cds for stuff i had back then |
11:41:16 | ashridah | sadly, that was before i discovered the wonders of ogg |
11:41:48 | ze | and employ a large breed of horse to anally rape internet explorer for intentionally not supporting png alpha channel |
11:42:40 | ze | ashridah: well ogg and flac have become popular enough now, you can often find copies of things available for download in them |
11:42:47 | ashridah | heh. fortunately, last time i had to do anything web-based, the lowest version of IE i had available was 5.5, which can be hacked around with javarsescript |
11:42:55 | ashridah | ze: yeah, that'd imply i had bandwidth tho |
11:43:02 | ze | hey man |
11:43:13 | ze | i was downloading 2-disc movie rips back when i was on modem |
11:43:30 | ashridah | yeah, except i've got a tv episode habit to keep up with :) |
11:43:42 | ze | heh |
11:43:51 | ashridah | 3 350MB episodes a week is a bitch when you're using torrents |
11:44:11 | linuxstb | ashridah: Why don't you just _tell_ people all your music is FLAC? |
11:44:14 | ze | hehe |
11:44:23 | ze | haha linuxstb has a point |
11:44:29 | ashridah | linuxstb: hahaha |
11:44:37 | ze | what're they gonna do, analyze the files on your player? |
11:44:44 | linuxstb | But FLAC support is very cool... |
11:45:02 | ze | yeah |
11:45:08 | ze | i got some flac copies of a few things some years ago |
11:45:18 | ze | and ended up getting a flac-capable player before i got around to transcoding them |
11:45:37 | ze | now if only the karma had opensource firmware... |
11:45:40 | ze | :/ |
11:45:43 | | Join preglow [0] (thomj@s183a.studby.ntnu.no) |
11:45:53 | preglow | it's not cooler than wavpack, though |
11:45:55 | preglow | i love the hybrid mode |
11:45:58 | ashridah | the sad part is i know some local artists who refuse to keep their original recordings in lossless formats. |
11:46:07 | ze | ashridah: that is sad |
11:46:23 | ze | they should burn the whole original session to cd/dvd's |
11:46:25 | ashridah | trying to justify it by claiming '320kbps doesn't lose anything noticable' |
11:46:29 | ashridah | then remixing it half a dozen times :) |
11:46:39 | ze | in the original seperate tracks and everything |
11:46:41 | ze | complete backup |
11:47:29 | ashridah | you'd think so |
11:47:31 | ze | then when they wanna transfer it to 6DOF 3D blueray ultradefinition audio or whatever |
11:47:45 | ze | it'll only sound sorta crappy rather than goddamn horrible |
11:47:45 | ze | heh |
11:48:06 | ashridah | ... blueray is horrible? |
11:48:13 | ze | er |
11:48:22 | ze | think a vinyl from the 20's put on CD |
11:48:25 | * | ashridah doesn't know his disk formats well |
11:48:33 | ze | not blueray itself |
11:48:51 | ashridah | ah, right. |
11:48:53 | ze | blueray is just higher-density optical storage |
11:48:53 | ze | heh |
11:49:24 | ashridah | you could probably do a decent reconstruction with a laser and several copies of the same vinyl these days |
11:49:27 | ashridah | should average out the defects |
11:49:41 | ashridah | depending on how the defects normally form. |
11:50:05 | ze | i was just talking about the transfer from original tracks vs transfer from lossy versions |
11:50:09 | ze | yeah |
11:50:23 | ze | a lot of the defects are from wear, which is probably pretty consistent among different copies |
11:50:28 | linuxstb | preglow: Am I right in assuming Rockbox doesn't support Wavpack correction files? |
11:50:29 | | Join Aison [0] (~hans@zux166-181.adsl.green.ch) |
11:50:47 | ashridah | ze: well, you'd attempt to find an unused copy |
11:50:57 | ze | but a laser scan of an unplayed or barely-played and well taken care of copy would probably sound pretty good |
11:51:07 | | Join tvelocity [0] (~tony@ipa78.5.tellas.gr) |
11:51:14 | ze | there's probably some pristine masters for most things |
11:52:35 | ze | of course that doesn't make up for defects in recording equipment or its usage |
11:52:40 | ze | or poor mixing and mastering skills |
11:53:17 | ze | though of course i dunno if mixing and mastering were really things that were done much in the 20's |
11:53:20 | ze | heh |
11:53:46 | ze | oh well |
11:53:52 | ze | anyway how'd it get to be 3am... bah |
11:55:29 | preglow | linuxstb: indeed |
11:55:34 | preglow | linuxstb: and it'll be hard to support as well |
11:56:11 | preglow | linuxstb: implementing it in the library we use would be pretty easy, i think, but buffering two files at once wont be so easy |
11:56:44 | linuxstb | Yep, it kind of destroys our streaming codec architecture. |
11:57:13 | preglow | linuxstb: luckily, for me at least, much of the point in having hybrid mode is the fact that i can just toss the compressed files minus the correctional files to my portable |
11:57:29 | preglow | the correctional file would pretty much just waste space |
11:57:35 | linuxstb | It would probably be possible with some kind of interleaving in the audio buffer - but probably only David could attempt that. |
11:57:40 | preglow | but it's nice to have in case i ever want a true lossless copy |
11:57:55 | preglow | we COULD interleave, yeah |
11:57:58 | preglow | that's a nice point |
11:58:14 | preglow | but indeed |
11:58:24 | linuxstb | But you can always re-encode a hybrid file to a single lossless file. |
11:58:25 | preglow | we're lucky to have a codec developer on the team |
11:58:28 | ashridah | it's how video/audio streams are usually dealt with. just have key data in the streams that keep the sample counts in check |
11:58:50 | preglow | it's nice not to have to worry about one particular codec, since the guy who happens to know the most about it is working on it anyway ;) |
11:59:05 | preglow | which isn't exactly the case with the other codecs |
11:59:25 | linuxstb | Yes - he's done a very good job integrating it into Rockbox. |
11:59:35 | preglow | codecwavpack is nice as well |
11:59:40 | preglow | supports fast seeking and all |
11:59:53 | preglow | and people say it's gapless |
12:00 |
12:00:06 | preglow | then again, a non-gapless lossless format would be kind of silly :P |
12:00:46 | linuxstb | Ah yes, military intelligence, friendly fire, non-gapless lossless... |
12:01:10 | preglow | we should make some kind of sample rate negotiation in the codec api |
12:01:23 | linuxstb | I think Apple have managed non-gapless lossless though... |
12:01:38 | preglow | apple can be as stupid as they want, as long as they look pretty |
12:02:06 | Bagder | I liked their early ipods, that never stopped spinning the disk when you played a song larger than the amount of ram |
12:02:13 | Bagder | :-) |
12:02:24 | preglow | haha |
12:02:33 | preglow | only thing i like about the ipod is the navigation wheel mechannism |
12:02:39 | preglow | i don't even think it looks very pretty |
12:02:50 | linuxstb | I'm not sure where the resampling should go - it can be argued that it should be done within the codecs because it could save yet another copy operation. |
12:03:10 | ashridah | crap! it's got that really great game where you shoot down helicopters and dudes in parachutes. it's clearly better than anything! |
12:03:26 | ashridah | infact, that game's better than all games that run on osX combined! |
12:03:27 | preglow | linuxstb: i think the codecs themselves shouldn't insert buffers, that'll have to go |
12:03:29 | ashridah | heh |
12:03:47 | preglow | linuxstb: they should just tell the codec api 'here is the pointer to a frame, do what you need with it' |
12:03:47 | linuxstb | preglow: What do you mean? |
12:04:07 | preglow | linuxstb: then the codec loader does whatever processing is needed, then inserts it into the audio buffer |
12:05:01 | linuxstb | The problem is that the codec libraries all deliver the uncompressed data in different formats. This needs to be converted to big-endian interleaved samples. |
12:05:11 | preglow | we will need a common format, yes |
12:05:23 | preglow | hmm, shit, that'll break fast interpolation |
12:05:31 | preglow | no it wont |
12:05:42 | linuxstb | My idea is that the resampling could happen at the same time as this conversion. But it may be one optimisation too far. |
12:05:50 | preglow | i hate interleaved data |
12:05:54 | preglow | it's bad for processing speed, heh |
12:06:06 | preglow | that's not a bad idea, actually |
12:06:45 | linuxstb | Thanks ;-). I don't think it's obvious where the resampling should go. |
12:07:10 | preglow | the interpolation coefficients can be chosen to do the shifting |
12:07:16 | preglow | as long as the shift isn't too big |
12:07:26 | preglow | but yes |
12:07:33 | preglow | it's crucial we design this so the codecs don't do it |
12:07:41 | preglow | that'll mean tons of code duplication |
12:08:02 | Bagder | unless we provide a nice set of functions |
12:08:16 | linuxstb | But the problem is that the "input format" varies with every codec. |
12:08:18 | preglow | Bagder: of course, but why not call those from a central place, then? |
12:08:35 | Bagder | I guess that depends on the data |
12:08:40 | preglow | it doesn't vary too much |
12:08:47 | preglow | resolution varies |
12:08:58 | preglow | interleaved/noninterleaved varies |
12:09:10 | preglow | i believe the codec loader should handle that as well |
12:09:10 | linuxstb | Flac has one array of 32-bit integers per channel, MAD uses it's own fixed-point format.... |
12:09:16 | preglow | point is, the possibilities aren't limitless |
12:09:27 | linuxstb | WAV is little-endian interleaved.... |
12:09:30 | preglow | linuxstb: well, yeah, but there's nothing to it other than a shift of variable size |
12:09:43 | preglow | linuxstb: endianness should be converted on load |
12:09:54 | linuxstb | If you can imagine the format, one of the codecs uses it. |
12:10:22 | Bagder | and probably a few additional ones we couldn't imagine ;-) |
12:10:32 | preglow | yes, but the possibilities aren't limitless, like i say, you've got either 16 bit or 32 bit data, either might have a variable size shift, and interleaved/noninterleaved |
12:10:42 | preglow | that's very manageable |
12:11:00 | preglow | dithering also should be done by rockbox, not the codecs |
12:11:05 | linuxstb | Or 24-bit in the case of libmad... |
12:11:13 | preglow | linuxstb: no, it's 32 bit |
12:11:22 | linuxstb | OK, sorry. |
12:11:29 | preglow | linuxstb: precision is 24 bit, though, but that's not the point |
12:12:36 | linuxstb | Maybe the resampling should go in playback.c for now, and if performance becomes an issue, we can think about moving it into the codecs. |
12:12:53 | preglow | why would it be any less of an issue there? |
12:13:08 | linuxstb | Because it can be combined with other operations. |
12:13:20 | preglow | they can be combined in playback.c as well |
12:13:36 | linuxstb | True. |
12:13:54 | preglow | as long as the codec delivers its buffers to playback.c with bit depth, precision and interleavedness specified |
12:13:58 | preglow | which should not be a problem |
12:13:59 | preglow | but of course |
12:14:11 | preglow | if we put them in the codecs, certain parameters code be inlined to the code |
12:14:19 | preglow | but then we'd need these routines in a header somewhere |
12:14:24 | preglow | codeclib or whatever |
12:15:01 | linuxstb | I think we've standardised on 16-bit, Stereo, big-endian interleaved at the moment. Some (but not all) the codecs do mono to stereo conversion. |
12:15:24 | preglow | that too is a job that doesn't belong there, imho |
12:15:29 | preglow | hmm |
12:16:04 | rasher | I see someone has been making battery tests.. why aren't the results on http://www.rockbox.org/twiki/bin/view/Main/IriverBattery I ask |
12:16:12 | linuxstb | I agree. audio_insertbuffer should probably take "nchannels" and "frequency" parameters. |
12:16:12 | preglow | rasher: ask [solid] |
12:16:43 | preglow | linuxstb: codecs should also be aware for what configuration they're generating data |
12:17:02 | preglow | linuxstb: liba52, for instance, has its own routines for downmixing which could be affected |
12:17:30 | preglow | i don't really believe we'll see portable with 5.1 configuration soon, though ;) |
12:19:01 | preglow | linuxstb: then again, output precision isn't fixed, uda1380 does support more bit depths than 16 |
12:19:06 | linuxstb | I posted a message to the linux-audio-dev list the other day - there are a few replies there with pointers to resampling code that may (or may not) be helpful. |
12:19:14 | preglow | linuxstb: url, please |
12:19:33 | linuxstb | http://music.columbia.edu/pipermail/linux-audio-dev/2005-June/ |
12:19:42 | linuxstb | ^Search for "resampling" in that page. |
12:20:10 | | Join hicks [0] (~hicks@193975afca3afbf3.session.tor) |
12:20:56 | preglow | sinc resampling is out of the question for us, imho |
12:20:58 | preglow | it's too memory intensive |
12:23:29 | preglow | so i'm still stuck with linear resampling for the case of 48->44.1 |
12:23:42 | preglow | for bigger rate changes i can cook up some filter trickery |
12:24:09 | rasher | does anyone know if Linus got the ihp-110? |
12:24:25 | preglow | he did |
12:24:38 | preglow | he'll be away for a while, though |
12:25:15 | rasher | Alrighty then. |
12:25:44 | | Quit rasher ("CGI:IRC") |
12:32:45 | | Join nick_ [0] (~irc@56e4593e34a71906.session.tor) |
12:43:46 | | Join MoosCamaro [0] (MoosCamaro@m214.net81-66-158.noos.fr) |
12:48:06 | | Join MO-Pantsu [0] (MO-Pantsu@deadman3000.plus.com) |
12:55:14 | | Join Patr3ck [0] (~patr3ck@p549E7ABF.dip.t-dialin.net) |
12:56:29 | | Quit Rori (Read error: 145 (Connection timed out)) |
13:00 |
13:12:20 | | Quit edx (Read error: 110 (Connection timed out)) |
13:25:12 | Slasheri | i am now at telecomm lab and i could take some power measurements from iriver IF i could find a molex connector that will fit the pcb |
13:37:49 | *** | Saving seen data "./dancer.seen" |
13:40:23 | preglow | sweet |
13:41:37 | | Join spiralout [0] (~keep_goin@p54B3B986.dip0.t-ipconnect.de) |
13:52:31 | HCl | pfff |
13:52:38 | HCl | bad idea to play san andreas till 4 am |
13:52:49 | * | HCl thinks he finally caught up on all the sleep he needed |
13:54:23 | preglow | please stop mentioning san andreas :/ |
13:54:48 | HCl | sorry |
13:54:49 | HCl | why? :/ |
13:55:59 | preglow | 'cause i wanna play it very, very badly |
13:56:05 | HCl | why don't you |
13:56:05 | HCl | ? |
13:56:11 | preglow | gotta finish school business |
13:56:15 | HCl | k k |
13:56:17 | HCl | sorry |
13:56:21 | preglow | and i'm bored out of my brain |
13:58:19 | Bger | HCl congrats for the sleep :) |
14:00 |
14:01:36 | preglow | i could boot windows and play for just a couple of hours... |
14:01:49 | HCl | doesn't sound smart :x |
14:01:58 | HCl | its pretty addictive |
14:02:04 | preglow | i happen to know that |
14:02:06 | HCl | k |
14:02:17 | preglow | i sat up to 4 am the other day myself |
14:02:24 | HCl | oh, right. |
14:02:35 | preglow | i'm addicted to motorcycle riding |
14:02:37 | preglow | it's so damn fast :/ |
14:02:39 | HCl | didn't know you've played it already |
14:02:47 | HCl | wait till you get to the planes |
14:02:51 | HCl | or the hovercrafts |
14:03:01 | preglow | i've tried the hovercraft |
14:03:03 | preglow | and i'm a master of planes |
14:03:06 | preglow | i played it on ps2 |
14:03:10 | HCl | oh, right |
14:03:23 | linuxstb | Mmm. I'm listening to a wavpack-encoded album, and half way through one song, it's started playing the second half of the previous song.... |
14:03:38 | linuxstb | But I had been playing with seeking earlier in the album. |
14:03:43 | preglow | ahh |
14:03:47 | preglow | there are buffering bugs still |
14:03:50 | preglow | i had that happen with mp3s |
14:03:56 | preglow | after toying around with seeking |
14:04:09 | preglow | wavpack too is very robust when it comes to seeking, so it probably went along with it |
14:04:29 | linuxstb | I'll stop seeking then... |
14:05:29 | linuxstb | Wavpack encoding is VERY fast though. Seems like a good candidate for encoding recordings in realtime. |
14:05:37 | preglow | it is |
14:05:40 | linuxstb | Unless it needs floats... |
14:05:42 | preglow | encoding == decoding, for wavpack |
14:05:49 | preglow | that's what david explained to me, at least |
14:06:01 | preglow | so encoding should actually be comperable to decoding in complexity |
14:06:05 | preglow | and wavpack is incredibly efficient as it is |
14:06:08 | linuxstb | It would also increase buffering time if we did real-time lossless encoding when recording. |
14:07:26 | preglow | shouldn't be a problem with wavpack, no |
14:09:06 | HCl | nice |
14:09:12 | HCl | so we can encode to wavpack, at least? |
14:09:15 | preglow | aye |
14:16:12 | * | MO-Pantsu can't seem to get Lame gapless to work that well. So I have dumped it for Ogg at least on my own rips |
14:16:59 | MO-Pantsu | does FF/RW work on Ogg yet? Not checked |
14:17:33 | linuxstb | MO-Pantsu: No. |
14:17:52 | MO-Pantsu | k |
14:18:45 | MO-Pantsu | I've kinda given up on gapless mp3 for now. it was not implemented into Lame until 3.89 anyhow which is why I'd prefer a generic gapless dsp |
14:19:14 | | Join Jim__ [0] (Owner@spr2-cosh3-5-0-cust23.cosh.broadband.ntl.com) |
14:19:34 | preglow | lame 3.89 has been out for ages |
14:20:09 | MO-Pantsu | I have a lot of old encodes I downloaded that are not Lame encoded. Some are even crappy Xing :P |
14:20:51 | | Join Patr3ck_ [0] (~patr3ck@p549E6AA1.dip.t-dialin.net) |
14:22:11 | ze | oh man, xing? |
14:22:19 | MO-Pantsu | lol |
14:22:35 | ze | man how did you not know better |
14:23:02 | Jim__ | hey! can anyone tell me what the image at the bottom of the screen when playing a song reprasents? Below how far into the song you are... |
14:23:15 | MO-Pantsu | hey when mp3 started everyone was using Fraunhoffer but then people complained about encoding speed and alll the n00bs found Musicmatch with Xing :P |
14:23:40 | preglow | Jim__: peak meter, i think |
14:23:42 | ze | yeah but encoding speed has never mattered except for prerelease rip groups |
14:23:48 | preglow | Jim__: not yet operational on iriver, if that's what you mean |
14:23:54 | ze | its all about the files you get |
14:23:55 | ze | heh |
14:24:16 | MO-Pantsu | I can't find many Ogg encodes :P |
14:24:18 | Jim__ | yer on iriver, thanks! |
14:25:07 | preglow | linuxstb: there's another thing we need to do while we're traversing the data we get from codecs, peak meter |
14:25:26 | | Quit Jim__ ("Chatzilla 0.9.68.5 [Firefox 1.0.4/20050511]") |
14:26:33 | MO-Pantsu | when Rockbox finally gets recording with meters it will become a usefull recording device. I hate guessing. |
14:27:00 | preglow | yes, indeed |
14:27:11 | MO-Pantsu | that's a way off though methinks :) |
14:27:25 | preglow | might be |
14:27:33 | preglow | we've got a guy recording with rockbox |
14:27:35 | preglow | on iriver |
14:27:52 | MO-Pantsu | cool |
14:28:50 | MO-Pantsu | the thing is will Rockbox do a live level check to meters in realtime with any degree of accuracy? :) |
14:29:02 | preglow | it'll be as accurate as we want |
14:29:11 | preglow | there's probably a clipping warning as well |
14:29:24 | MO-Pantsu | that would rule |
14:30:00 | MO-Pantsu | it would become 'the' defacto DAP for taking to concerts etc |
14:30:03 | preglow | automatic gain reduction on clip wouldn't be too hard either |
14:30:04 | preglow | if you want that |
14:30:49 | HCl | i really need to stop playing san andreas |
14:30:51 | HCl | check out rockbox |
14:30:54 | HCl | and work on the searchengine.. |
14:30:57 | MO-Pantsu | maybe. I prefer to find a level and sit with it coz it stops the pumping effect |
14:30:57 | preglow | DUBM |
14:30:58 | preglow | DUBM |
14:31:00 | preglow | DUMB <- |
14:31:04 | HCl | that too |
14:31:17 | preglow | MO-Pantsu: yes, sure, me too, but in some situations you don't have time to calibrate |
14:31:23 | MO-Pantsu | true |
14:31:56 | MO-Pantsu | never liked compression (Except for fat kick drums) :) |
14:32:27 | MO-Pantsu | compression & limiting can be usefull for some stuff |
14:32:38 | preglow | well, it's not compression |
14:32:45 | preglow | it's just a one-shot gain reduction |
14:32:45 | MO-Pantsu | I know just mentioning it |
14:33:06 | preglow | if it were to constantly readjust recording gain, it might sound like compression |
14:33:12 | preglow | but i don't like that, heh |
14:33:36 | MO-Pantsu | brb |
14:33:36 | | Quit Patr3ck (Read error: 110 (Connection timed out)) |
14:37:02 | linuxstb | preglow: Is the peakmeter something for the firmware to take care of? Maybe the hardware can give us that information back. |
14:37:50 | preglow | sincerely doubt it |
14:38:25 | linuxstb | I'm sure that's how it works on the Archos, so maybe some hardware can do it, even if the iRiver can't. Just a thought. |
14:40:11 | linuxstb | Does the famous iRiver "recording glitch" happen with both analogue and digital inputs, or is it just a digital problem? |
14:40:30 | MO-Pantsu | preglow: you know you was saying the other day you could not get rid of the glitch in lame gapless mp3's and could not figure out why? |
14:40:40 | preglow | MO-Pantsu: yes |
14:40:46 | preglow | linuxstb: some people report both |
14:40:58 | MO-Pantsu | did you try encoding using deprecating commandline in lame? |
14:41:33 | preglow | what depracated commandline? |
14:41:36 | MO-Pantsu | IE: lame −−nogap −−alt-preset standard track1.wav track2.wav track3.wav |
14:41:46 | preglow | i don't care about −−nogap, that should work |
14:41:50 | preglow | −−nogap is a hack |
14:42:08 | MO-Pantsu | apparently −−nogap don't work too well unless eaither successive track is encoded in one commandline |
14:42:14 | preglow | of course |
14:42:20 | preglow | it doesn't work at all |
14:42:25 | MO-Pantsu | oh ok |
14:42:33 | preglow | lame specifically says you HAVE to give it _all_ wav files |
14:42:34 | MO-Pantsu | just checking coz I can't get it to work either |
14:42:45 | linuxstb | I think −−nogap is a good idea. Problem is with rippers that rip and and encode one track at a time. But even those could be made to work (by moving samples itself). |
14:42:48 | preglow | if you just give lame one wav, −−nogap doesn't do shit |
14:42:51 | MO-Pantsu | I used winLame that supposedly does that for you |
14:43:10 | preglow | linuxstb: i think it's a horrible hack, i want my track transitions to be where they're supposed to be |
14:43:13 | MO-Pantsu | but it still glitched so shrugs |
14:43:16 | linuxstb | It's like "sector boundary errors" with CD audio - you need to burn CD audio in multiples of 2352 bytes, and the same limitation applies to MP3. |
14:43:24 | MO-Pantsu | yes it sucks |
14:43:39 | MO-Pantsu | it all sucks |
14:43:41 | MO-Pantsu | heh |
14:43:52 | preglow | MO-Pantsu: it might glitch now with my current code |
14:43:57 | preglow | MO-Pantsu: it didn't glitch before |
14:44:07 | MO-Pantsu | hmm |
14:44:25 | preglow | we'll have it working, don't worry |
14:44:30 | MO-Pantsu | ;) |
14:44:31 | preglow | but don't expect mp3 playback to just work nmow |
14:44:35 | preglow | it's under development |
14:44:39 | linuxstb | But moving the transitions a few ms won't make any difference - in fact it makes no difference at all if you are playing back the album sequentially. |
14:44:40 | MO-Pantsu | no worries |
14:44:52 | preglow | linuxstb: 'course not, but still |
14:45:09 | preglow | linuxstb: it's still a hack, lame info header gapless makes it redundant |
14:45:40 | linuxstb | Only for players that support it. The −−nogap option makes MP3s that play gaplessly anywhere - assuming the player doesn't add extra silence between tracks. |
14:46:01 | linuxstb | That's why I think it's a useful solution. |
14:46:32 | preglow | a lot of players do add extra slence |
14:46:39 | preglow | iriver, ipod, creative players |
14:46:42 | preglow | so it doesn't matter |
14:46:51 | preglow | works for archos, of course |
14:47:12 | linuxstb | That's true - −−nogap is the only way to get gapless on the Atchos. |
14:48:04 | MO-Pantsu | probably be easier to add cue file support and if people want gapless in mp3 rip it as a single file |
14:48:09 | MO-Pantsu | heh |
14:48:18 | | Join edx [0] (edx@p54A8C11A.dip.t-dialin.net) |
14:48:52 | linuxstb | Yes, I'm very keen on cue files - I even wrote a patch to Rockbox a few years ago, but it never made it into the official code. |
14:49:13 | preglow | cue sheet support should be a breeze this time around |
14:49:19 | preglow | if you don't demand too much precision |
14:49:51 | MO-Pantsu | true that I note when you reburn a cd from a cue file the points are not the same |
14:50:09 | linuxstb | I think we should aim for sample-accurate seeking for those codecs that support it. |
14:50:21 | MO-Pantsu | do any? |
14:50:21 | preglow | well |
14:50:33 | preglow | mp3 is the only format that benefits from cue support |
14:50:41 | preglow | and sample-accurate mp3 is a serious pain in the ass |
14:50:45 | MO-Pantsu | mp3 only goes to the next frame |
14:51:16 | MO-Pantsu | to make it work accurate would need to be after the decoder stage |
14:51:30 | preglow | nah, it needs to be in the decoder |
14:51:32 | DaKi][er | would it show the segments of the whole file in the file browser or just the .mp3 and .cue in there? |
14:51:52 | preglow | the decoder has to walk the bitstream until it finds the frame it needs, then it needs to decode until it finds the sample it needs |
14:51:56 | MO-Pantsu | well when I have edited mp3's in mp3directcut I can never get to the exact point |
14:52:00 | preglow | this is painfully slow even on my atlon64 |
14:52:29 | preglow | mp3 is a dirty bitch |
14:52:36 | MO-Pantsu | aye |
14:52:42 | MO-Pantsu | slut even |
14:52:45 | preglow | oh, yes |
14:52:47 | linuxstb | I would be more than happy for Rockbox to have a "slow but accurate seeking" mode that scans the whole file. But I think others would be happier with a "fast but inaccurate" mode. |
14:53:05 | preglow | linuxstb: would probably be nice to be able to save the resulting seektable |
14:53:31 | linuxstb | I agree. Or even calculate it off-line. |
14:54:07 | linuxstb | Does anyone know anything about Matroska? Would that give us a seektable if we wrapped MP3 files in a Matroska container? |
14:54:44 | MO-Pantsu | I am thinking about attacking some of my MP3 collections where I don't own the original CD and using winamp with a output stacker and realtime them out to wav files using the ds output to achieve gapless on those non-lame files. dirty. don't like re-encoding and it would take a while but should work. |
14:55:12 | linuxstb | My requirement is that I make lots of recordings from radio (in MP2 format), and often index them using a cuefile. I know I can split them, but would prefer a single long file. |
14:56:00 | MO-Pantsu | you can embed cue in the file (at least in mp3 I know you can) |
14:56:34 | tvelocity | in a tag? that sucks |
14:56:52 | linuxstb | MO-Pantsu: It makes no difference where the cue information is stored, the work is to make Rockbox actually use them properly. |
14:56:59 | MO-Pantsu | yeah well would be if you want to reburn it |
14:57:01 | preglow | MO-Pantsu: rockbox might very well end up supporting the winamp gapless method |
14:57:08 | preglow | don't jump to any conclusions |
14:57:22 | MO-Pantsu | I would kiss your booty if it did ;) |
14:57:32 | MO-Pantsu | ooer |
14:58:19 | linuxstb | Are there any standard ways to store seektables in MP3 files? Does the Xing VBR header do that? |
14:58:41 | MO-Pantsu | but this is my - how many days now? 3rd or 4th day talking about gapless. Beginning to sound like a spoilt brat. I shall endeavour not to mention it again for a while at least |
14:59:10 | MO-Pantsu | I am re-ripping the CD's I own to Ogg as I type |
15:00 |
15:00:40 | preglow | linuxstb: yes, there are |
15:00:53 | preglow | linuxstb: only for vbr files, though, but then again cbr SHOULD be easily seekable |
15:01:04 | linuxstb | MO-Pantsu: Why don't you rip to FLAC? Then you can re-encode to any lossy format in the future without having to re-rip. |
15:01:06 | tvelocity | speaking of ogg, how is rockbox handling multiple streams in an ogg file? |
15:01:06 | preglow | linuxstb: the xing header contains a hundred seek points, the less common vbri header contains a variable amount |
15:01:25 | MO-Pantsu | linuxstb it's all about the storage space :) |
15:01:39 | linuxstb | MO-Pantsu: DVD-R? |
15:01:55 | MO-Pantsu | It's OK I am happy with this method |
15:01:58 | linuxstb | preglow: Does Rockbox use the seekpoints? |
15:02:11 | preglow | linuxstb: it uses xing seek points, it does not yet use the vbri ones |
15:02:41 | | Nick mbr_ is now known as mbr (~mb@stz-softwaretechnik.de) |
15:02:47 | * | MO-Pantsu wants his new psu to arrive. Fedup of the noisey failing psu currently in there |
15:03:12 | linuxstb | I've written my own software to record DVB radio to MP2 files (under Linux) - I may think about adding those headers to the output files. |
15:03:32 | preglow | those files are cbr, no? |
15:03:52 | linuxstb | Yes, but they can (in theory) have a padding byte in some of the frames. |
15:03:57 | hicks | Anyone here use gentoo? |
15:04:01 | preglow | hicks: aye |
15:04:14 | linuxstb | However, I don't think that's used by any of the radio stations I record from. |
15:04:22 | preglow | linuxstb: what's the point? |
15:04:28 | linuxstb | Of what? |
15:04:31 | hicks | How did you setup the cross compiler? Did you use crossdev, or a portage overlay or manual installed it in your home dir? |
15:04:31 | preglow | linuxstb: padding |
15:04:38 | preglow | hicks: i compiled it by hand |
15:04:43 | linuxstb | I have no idea. |
15:04:44 | preglow | hicks: in my home dir |
15:05:06 | hicks | ok,cheers :) |
15:05:36 | MO-Pantsu | I want a DVR with network support and no copy protection |
15:05:55 | linuxstb | Freevo, MythTV ? |
15:05:57 | preglow | hmm |
15:05:59 | MO-Pantsu | Copy the MPEG2 stream directly without loss. That would be so nice. |
15:06:02 | preglow | wavpack deecodes lossy files much, much slower |
15:06:18 | linuxstb | Is it still realtime? |
15:06:28 | preglow | linuxstb: what bitrate/sample rate do they transmit? |
15:06:47 | linuxstb | Generally 192kbps/48KHz. Sometimes Stereo, sometimes Joint-Stereo |
15:07:05 | | Join Sucka [0] (~NNSCRIPT@host81-156-209-158.range81-156.btcentralplus.com) |
15:07:14 | preglow | i've got a 192kbps 44.1khz mp2 file, and it sounds completely decent |
15:07:18 | preglow | i can't spot any artifacts |
15:07:41 | preglow | even though they say mp2 required 128kbps per channel for transparency |
15:07:58 | preglow | i think subband codecs sound nicer than more complex transform codecs anyway |
15:08:02 | linuxstb | Only problem is the 15KHz-16KHz cut-off - they do sound "flatter" than analogue radio. I like high-frequency noise... |
15:08:06 | preglow | that's why i'm a bit partial to musepack |
15:08:25 | preglow | i can't hear frequencies above 16khz anyway, heh |
15:09:33 | linuxstb | Isn't musepack a "fork" of MP2? |
15:09:39 | preglow | kind of |
15:09:48 | preglow | it's based on the same concepts |
15:10:09 | preglow | i like it, it's simple and neat, no windows or anything |
15:10:41 | preglow | just splits the signal into different frequency bands and quantises the different bands according to what we can hear |
15:11:15 | preglow | mp3 does basically the same thing, but uses a nasty mdct per filter band as well |
15:11:24 | | Quit DMJC ("Leaving") |
15:11:29 | preglow | which gives the "nice" artifacts at low bitrates |
15:12:02 | linuxstb | It just seemed too much work to keep up to date with all the various lossy codecs, so I just chose FLAC. |
15:12:29 | preglow | haven't got enough disk space for that, i'm afraid |
15:12:52 | preglow | keeping all my music ripped as flac would require me buying another disk, heh |
15:12:55 | linuxstb | I also sometimes actually listen to CDs... |
15:13:02 | preglow | sure, i listen to cds all the time |
15:13:13 | preglow | i occasionally listen to vinyl as well |
15:13:28 | preglow | i like physically handling my music from time to time ;) |
15:13:42 | tvelocity | i only touch my CD's to rip them |
15:13:42 | tvelocity | :P |
15:14:19 | tvelocity | or maybe to admire it's booklet's etc |
15:14:25 | tvelocity | but never to listen to it:P |
15:16:46 | | Join Chamois [0] (HydraIRC@champigny-5-82-226-182-23.fbx.proxad.net) |
15:17:27 | | Quit ashridah ("sleep") |
15:23:56 | | Join DMJC [0] (~DMJC@60-240-161-237.tpgi.com.au) |
15:24:51 | MO-Pantsu | I listen to DTS CD's |
15:31:30 | | Quit scriptkitty (Read error: 110 (Connection timed out)) |
15:37:53 | *** | Saving seen data "./dancer.seen" |
15:39:28 | | Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
15:52:27 | preglow | linuxstb: it's quite obvious it's the lack of seeking that's killing mpc, btw |
15:52:32 | preglow | linuxstb: the very first thing it does it try to seek |
15:52:46 | preglow | linuxstb: completely disregarding it's own can_seek function |
15:53:54 | linuxstb | Do you know where it tries to seek to? |
15:54:09 | preglow | to the first proper mpc frame, it seems |
15:54:30 | linuxstb | So is it just seeking forwards? |
15:55:28 | preglow | it first seeks to the start of the file |
15:55:34 | preglow | it fails there already |
15:55:38 | preglow | then it tries to seek again |
15:55:46 | preglow | i wonder why the hell they implemented can_seek |
15:55:53 | linuxstb | :-) |
15:56:25 | linuxstb | Maybe we can add two special cases to the seek function in codecmpc - seeking forward (replace by read) and seeking to ci->curpos (to take account of the initial seek). |
15:56:48 | linuxstb | s/read/advance_buffer/ |
15:57:59 | | Join ehntoo [0] (~noclue2@24-177-161-77.dhcp.mrqt.mi.charter.com) |
15:58:44 | preglow | you could try, of course |
15:59:54 | preglow | i don't think it even needs to seek, provided you don't have id3v2 data patched in front of the stream |
16:00 |
16:00:02 | preglow | but it does of course check seeks return value nonetheless |
16:01:16 | linuxstb | Is the offset parameter to seek_impl the offset from the start of the file? |
16:02:11 | preglow | believe so |
16:02:12 | preglow | hmm |
16:02:14 | preglow | i made it return true |
16:02:17 | preglow | but still no dice |
16:02:22 | preglow | it just tries longer before it fails |
16:02:37 | linuxstb | I'm just trying my hack now. |
16:03:19 | preglow | my files has no id3 |
16:03:24 | preglow | file |
16:03:32 | linuxstb | I have implemented seeks forward, and seeks to the current position. |
16:03:53 | preglow | good |
16:03:56 | preglow | it does a seek forward, i see |
16:04:38 | linuxstb | No. :-( It just takes longer to fail. |
16:05:35 | preglow | try logging in seek |
16:05:41 | preglow | to see if it ever tries seeking backwards |
16:06:00 | linuxstb | How do I log from a plugin? I don't think logf is exported. |
16:06:12 | preglow | fdprintf :-) |
16:06:25 | preglow | logf not being supported is a crying shame |
16:06:32 | preglow | i'm considering just implementing it locally |
16:06:45 | linuxstb | logf should be added to the plugin API. |
16:07:11 | preglow | bagder didn't want it to |
16:07:19 | preglow | i can't see why, but there it is |
16:07:59 | preglow | there'll be a function call overhead if its not used |
16:08:14 | preglow | but anywho, i'll enable it locally |
16:08:20 | preglow | it really helps debugging |
16:09:28 | linuxstb | It could be disabled via #ifdefs - it's only used by developers anyway. |
16:09:57 | | Join DMJC-L [0] (~DMJC-L@60-240-161-237.tpgi.com.au) |
16:10:18 | preglow | you'd have to wrap every logf usage with #ifdef DEUG |
16:10:20 | preglow | DEBUG, even |
16:10:36 | linuxstb | Use a LOGF macro |
16:10:39 | preglow | or better yet |
16:10:41 | preglow | LOGF macro, yes |
16:10:54 | preglow | LOGF(rb, "lol %s", hehe); |
16:11:43 | preglow | we could also constantly keep logf() at the end of the plugin api struct, so it'll never bother anyone |
16:12:11 | preglow | i'll go outside and enjoy the weather for a bit, brb |
16:17:49 | preglow | damn |
16:17:53 | preglow | seems like summer finally arrived |
16:20:21 | bipak | hi |
16:20:59 | | Join B4gder [0] (~52b61a05@labb.contactor.se) |
16:21:12 | B4gder | for the reconrd, I _do_ want logf() in the plugin API |
16:21:31 | B4gder | or logf functionality at least |
16:21:39 | Bger | B4gder:)) |
16:21:59 | preglow | B4gder: aight, then someone has misrepresented your opinion ;) |
16:22:05 | * | t0mas doesn't see a record function on iriver yet... sorry,,, can't record you ;-) |
16:22:29 | HCl | Slasheri: awake? |
16:29:42 | t0mas | B4gder? |
16:30:12 | t0mas | awake too? :) |
16:30:40 | t0mas | (or amiconn? / preglow? / Linus? / Zagor?) |
16:31:04 | preglow | B4gder: but yeah, with a #ifdef HAVE_LOGF \n define logf() entry at the end of the plugin api struct, and a LOGF macro, shouldn't we be ok? |
16:31:41 | B4gder | logf() is a macro if built without logf |
16:31:45 | preglow | ahh, yes |
16:31:48 | preglow | but with a wrapper function |
16:31:59 | preglow | plugin_logf, or something |
16:32:08 | B4gder | yeps, I'm fine with that |
16:32:21 | t0mas | ok, next design issue :) |
16:32:23 | preglow | anywho |
16:32:26 | t0mas | the wps on remote... |
16:32:40 | t0mas | shouldn't we separate all displaying functions in tree, menu and wps? |
16:32:52 | t0mas | and make 1 sort of lib/api for it? |
16:33:07 | preglow | if we wrap the logf function pointer in the api struct with ROCKBOX_HAVE_LOGF, we shouldn't need it, since the compiler will never see logf() then |
16:33:12 | t0mas | so we can easily use it on other size screens (portability) and on the remote? |
16:33:40 | B4gder | preglow: but there is no logf() function if built without it |
16:33:43 | Slasheri | HCl: yes :) |
16:34:53 | B4gder | I'm off again |
16:34:55 | | Quit B4gder ("CGI:IRC") |
16:35:30 | | Quit elinenbe_ (" Want to be different? HydraIRC -> http://www.hydrairc.com <-") |
16:45:45 | linuxstb | preglow: codecmpc firstly seeks to 0 (with ci->curpos==0) and then seeks to 0 again (but when ci->curpos==10). |
16:46:01 | linuxstb | So it's the second seek that now fails. |
16:46:22 | preglow | gharhgh |
16:46:33 | preglow | could you try commenting out the seeks? :-) |
16:46:53 | linuxstb | From where? libmusepack? |
16:47:04 | preglow | yes |
16:47:27 | linuxstb | I'll have a look. |
16:49:00 | | Join tksu [0] (~3ef89a0e@labb.contactor.se) |
16:50:10 | tksu | hi, great work guys! I just flashed my player and am really hyped... gotta start learning that c now |
16:50:30 | tksu | is the splitedit plugin removed from iriver builds on purpose? |
16:50:36 | preglow | probably |
16:50:36 | preglow | ) |
16:50:59 | tksu | okay.. just said that iriver is supported in the wiki and it had button mappings and everything |
16:51:10 | tksu | but, i'll wait :) |
16:51:47 | preglow | do that |
16:53:51 | | Part tksu ("congrats to all") |
16:54:38 | | Nick StrathAFK is now known as Strath (~mike@dgvlwinas01pool0-a219.wi.tds.net) |
16:59:59 | | Quit thegeek_ (Read error: 131 (Connection reset by peer)) |
17:00 |
17:00:10 | linuxstb | I may be wrong, but I think splitedit relies on the peakmeter - which isn't implemented on the iRiver yet. |
17:01:55 | t0mas | wasn't it working with the mas chip? |
17:02:03 | t0mas | and iriver doesn't have one... |
17:03:26 | crwl | what about the bass/treble settings, are they easy to implement on iriver (ie. on hardware side) |
17:04:22 | preglow | crwl: yes, i've already done it, but i'm waiting for some stuff from austriancoder |
17:04:34 | preglow | it's really simple to do, but i don't want to crash his fixes as well |
17:05:24 | linuxstb | libmusepack is seek-crazy when opening a file... |
17:06:11 | crwl | preglow, okey |
17:07:07 | preglow | damn, how easy musepack is determined to be on us |
17:09:23 | linuxstb | I can't get it to work - we need a proper solution. But I can't do any more now. |
17:09:57 | linuxstb | It keeps wanting go to back a few bytes. I think more time needs to be spent fixing libmusepack to remove those seeks properly |
17:10:02 | preglow | seems like the coder is going to drop by afterwards |
17:22:33 | | Quit tvelocity ("Leaving") |
17:25:32 | | Quit spiralout (Read error: 104 (Connection reset by peer)) |
17:25:42 | | Nick MoosCamaro is now known as Moos- (MoosCamaro@m214.net81-66-158.noos.fr) |
17:26:33 | | Nick Moos- is now known as Moos (MoosCamaro@m214.net81-66-158.noos.fr) |
17:30:47 | t0mas | lol |
17:31:41 | t0mas | OO.org didn't like opening 15 documents at once |
17:31:53 | bipak | ;) |
17:32:03 | bipak | sry, wrong window |
17:32:20 | Slasheri | t0mas: Hehe. I hope you are not editing any source code with openoffice ;) |
17:33:18 | t0mas | ofcourse I am |
17:33:26 | t0mas | don't you like different size sourcecode? |
17:33:32 | t0mas | with tables... and a print playout? |
17:33:35 | Slasheri | :D |
17:33:39 | t0mas | oh and nice changeable colors... |
17:33:41 | preglow | Slasheri: you got any idea what the seeking bugs are caused by? |
17:33:44 | t0mas | and every few lines a new font |
17:33:51 | Slasheri | preglow: yep, forward seeking is fixed :) |
17:33:58 | Slasheri | or it should be, please test |
17:34:06 | preglow | Slasheri: the bug where you suddenly are skipped right into the middle of another song, yes? |
17:34:12 | Slasheri | yeah |
17:34:13 | preglow | ooh, lookie there |
17:34:16 | t0mas | (but no, I was just opening a word document... and it choked on some MS shit) |
17:34:18 | preglow | great! |
17:34:31 | Slasheri | i think the latest commit should fix those, but i can't be sure |
17:34:44 | preglow | yes, it's not an mp3 specific fix? |
17:34:50 | Slasheri | nope |
17:35:00 | preglow | great, 'cuz it happened for wavpack as well ;) |
17:35:08 | preglow | might test afterwards |
17:35:18 | Slasheri | it was a problem with all file types that support seeking |
17:35:51 | crwl | what about that queue/insert playlist/modify playlist when the next tracks are already buffered thing? ;) |
17:36:32 | Slasheri | crwl: i don't know yet about that.. :/ |
17:37:01 | Plugh_ | I recorded 18 hours on my FMR using a build from last week, and a lot of the tracks (74 min splits) are unplayable on anything but the recorder. Does anyone know of some good vbr fixing programs that deal with the buggy recording? |
17:37:30 | Plugh_ | the mp3 are showing in the WPS as fixed bitrate mp3, which I know isn't true |
17:37:43 | preglow | does seek_buffer work together with read_filebuf? |
17:37:54 | Slasheri | preglow: yes it should |
17:37:58 | *** | Saving seen data "./dancer.seen" |
17:38:00 | preglow | hmm |
17:38:11 | preglow | i'll try hacking that into musepack, then |
17:38:15 | Slasheri | :) |
17:38:26 | | Join hardeep [0] (hardeeps@192.94.73.30) |
17:38:32 | Slasheri | but remember that backward seeking is only partially implemented |
17:39:06 | hardeep | hi all |
17:39:27 | hardeep | nice work on the iriver, it's working great |
17:39:34 | preglow | we need to seek backwards a couple of bytes, i think |
17:39:48 | Slasheri | maybe some configuration options should be added to codec interface to support files better that require more seeking |
17:40:04 | Slasheri | ok, currently that is a problem if those bytes are not buffered |
17:40:27 | preglow | i've got musepack |
17:40:34 | linuxstb | I don't think libmusepack _requires_ seeking - it's just how it works at the moment. i.e. I think it could be rewritten to remove those seeks. |
17:40:45 | Slasheri | (buffer will be cleared if seeking more bytes that are currently available in the buffer) |
17:40:46 | preglow | it's so incredibly not realtime |
17:41:09 | linuxstb | preglow: What did you have to do? |
17:41:23 | preglow | linuxstb: just call seek_buffer from musepacks seek callback |
17:41:40 | linuxstb | :-). Simple. |
17:41:49 | preglow | return ci->seek_buffer(offset); |
17:42:18 | preglow | but yeah |
17:42:24 | preglow | the codec is so incredibly inefficient as it is |
17:42:42 | Slasheri | preglow: btw, currently seek_buffer returns only true or false.. =) |
17:42:57 | preglow | the fact that it works even partially is a miracle deserving of jumping and loud shouting |
17:42:58 | Slasheri | Maybe it should be fixed to return the position |
17:43:06 | preglow | Slasheri: that's how musepack seek likes it |
17:43:11 | Slasheri | ah, ok |
17:43:47 | preglow | curse this bloody codec to hell |
17:44:12 | preglow | i'll just do a nasty hack and see how the audio turns out |
17:46:12 | | Join markun [0] (~markun@bastards.student.ipv6.utwente.nl) |
17:47:00 | markun | t0mas, you there? |
17:52:46 | | Quit nick_ (" ") |
17:55:19 | hardeep | Slasheri: implementing audio_flush_and_reload_tracks() would fix the problem with buffered tracks and modifying the playlist |
17:55:27 | bipak | could someone update the daily build changelog? :> |
17:56:02 | Slasheri | hardeep: ah, thanks :) |
17:56:21 | Slasheri | then that should be implemented :) |
17:57:20 | Slasheri | hardeep: when audio_flush_and_reload_tracks is called, will playlist_peek(0) return the right track to start buffering with? |
17:57:37 | hardeep | Slasheri: yeah |
17:57:40 | Slasheri | great |
17:57:52 | hardeep | although in the mpeg code, we only flushed the tracks that weren't being played |
17:58:27 | Slasheri | ah, so everything doesn't need to be reloaded from disk |
17:59:02 | Slasheri | i will implement that :) |
17:59:25 | | Quit Patr3ck_ () |
17:59:39 | crwl | whee ;) |
17:59:50 | Slasheri | crwl :) |
17:59:53 | crwl | hehe |
18:00 |
18:02:04 | | Join Shagnar [0] (~tester@p54A0CAD6.dip.t-dialin.net) |
18:02:35 | HCl | Slasheri: is that track event thing done yet? |
18:03:57 | Slasheri | HCl: Not yet.. You would need exact information when the track is changed? |
18:04:15 | Slasheri | I can do that.. I will try to do it soon ;) |
18:05:24 | t0mas | markun: yes I am |
18:07:38 | markun | t0mas: I tried to enable seeking with the remote, but it didn't work, do you want to take a look at it? |
18:07:47 | t0mas | ofcourse |
18:07:56 | t0mas | I'm a little busy... |
18:08:02 | t0mas | so maybe you can email it? |
18:08:13 | preglow | hahaha |
18:08:17 | HCl | Slasheri: well, i need events on when a track gets played |
18:08:18 | HCl | and its filename |
18:08:22 | t0mas | my firstname@lastname.nl |
18:08:22 | preglow | i lose 17 bits of accuracy to make musepack work |
18:08:26 | t0mas | tomas and Salfischberger |
18:08:38 | preglow | less then sixteen bits remain |
18:08:40 | t0mas | markun: and you can do it in dutch... |
18:09:48 | markun | I know, but It's not very kind to the other people in the forum.. |
18:10:20 | t0mas | forum is ok too |
18:10:28 | t0mas | just drop it somewhere so I can read it tonight... |
18:11:15 | markun | ok, I'll mail it |
18:20:03 | CoCoLUS | hi |
18:20:14 | CoCoLUS | preglow, about the bass/treble settings... |
18:20:22 | CoCoLUS | you said you'll wait for austriancoder? |
18:21:00 | preglow | yes |
18:21:20 | CoCoLUS | could you tinker some unofficial patch for the curious? :) |
18:23:20 | preglow | nope |
18:23:26 | preglow | no time, sorry |
18:23:28 | preglow | brb |
18:24:28 | CoCoLUS | when do you think austriancoder will be ready? |
18:25:18 | CoCoLUS | sorry for being annoying but thats the only thing keeping me from using rb during normal usage :) |
18:25:42 | preglow | i don't know, he said he should have commited it yesterday or earlier |
18:25:45 | preglow | but it didn't happen |
18:25:47 | preglow | brb for real now ;) |
18:30:34 | markun | preglow: about replaygain, I think we should tell the decoder to scale down if the peak value is too high to prevent clipping and then recalculate the replaygain value and adjust the volume. |
18:31:31 | | Nick QT_ is now known as QT (as@area51.users.madwifi) |
18:45:32 | HCl | didn't austriancoder lose his iriver? |
18:46:02 | | Join tvelocity [0] (~tony@ipa78.5.tellas.gr) |
18:46:16 | markun | he lost it? |
18:46:22 | HCl | well |
18:46:23 | HCl | damage it |
18:46:27 | preglow | yeah, he did |
18:46:33 | markun | damn |
18:46:38 | * | HCl prods Slasheri |
18:46:47 | preglow | markun: we need to think about that, i'd really like it if the codec loader did the scaling |
18:47:30 | markun | The scaling to prevent clipping or also the replaygain? |
18:48:39 | markun | I think it would be best to keep the resolution as high as possible and use the mixer to do the replaygain, no? |
18:50:03 | markun | Or would you like to 32-bit samples from the codec (in the case of Tremor) and then have a central place that does the output conversion and clipping prevention? |
18:50:17 | markun | .. like to get .. |
18:53:15 | preglow | everything i've seen outputs 32 bit samples |
18:53:33 | preglow | so a central place would be great |
18:53:36 | markun | yes |
18:53:39 | preglow | we don't only need to do scaling |
18:53:45 | preglow | we also need to do shifting and resampling |
18:53:48 | preglow | and possibly eq |
18:53:49 | markun | true |
18:53:50 | preglow | and other effects |
18:55:41 | preglow | so the codecs could instead of talking directly to the pcm buffer driver, talk to some codec loader function |
18:55:53 | linuxstb | A quick audit: FLAC outputs 32-bit host-endian non-interleaved integers |
18:56:16 | linuxstb | WAV is little-endian 16-bit interleaved integers |
18:56:21 | preglow | wavpack outputs 32 bit little endian, i think |
18:56:38 | preglow | so yeah |
18:58:03 | linuxstb | A52 is a 32-bit fixed-point representation (non-interleaved) |
18:58:27 | preglow | both libmad and tremor output 32 bit fixed point in host endian |
18:58:33 | preglow | libmad non-interleaved |
18:59:00 | linuxstb | Vorbis is 16-bit host-endian interleaved |
18:59:55 | preglow | zit? |
18:59:59 | preglow | but yeah |
19:00 |
19:00:07 | preglow | we obviously need the function to handle both cases |
19:00:26 | Slasheri | HCl: Hmm, you don't need the exact time when the track is changed? (however, i can do also that later) |
19:00:32 | linuxstb | Yep - the data returned by ov_read is passed directly to the audio_insertbuffer function. |
19:00:56 | Slasheri | HCl: If +- few seconds is ok, i can do it very soon |
19:02:04 | linuxstb | preglow: It could be useful to support 24-bit FLAC files - they are becoming more common in live music trading circles. |
19:02:23 | crwl | 24-bit FLAC = FLAC encoded from 24 bit source? |
19:02:33 | linuxstb | crwl: Yes. |
19:03:28 | HCl | Slasheri: yea, it is |
19:03:50 | HCl | timing isn't too important, as long as it gets the filename of the track that finished playing |
19:04:07 | HCl | and as long as it only gets called once for each time it finished playing |
19:04:45 | hicks | Anyone else get a compilation error with the latest cvs? For h100 target failing on "Make in dumb" (dumb) CC src/it/itread.c |
19:04:57 | | Quit hardeep ("BitchX: all the things phone and hop won't include") |
19:05:00 | hicks | saying insn does not satisfy its constraints. |
19:06:07 | markun | linuxstb: in vorbisfile.c the samples are converted to 16 bit, we cound change the code to output the original 32 bit. |
19:06:15 | HCl | nope, it compiled here fine |
19:06:25 | Slasheri | HCl: ok, i can do that :) |
19:06:37 | HCl | :) |
19:06:38 | HCl | please |
19:06:42 | preglow | linuxstb: that shouldn't be a problem, just specify a bigger shift factor to the output function |
19:06:46 | preglow | that is, if we choose to do it that way |
19:06:48 | hicks | hmm. Are you using binutils 2.16 and gcc 3.3.4? |
19:07:07 | preglow | 3.4 |
19:07:10 | preglow | 3.3 wont work |
19:07:17 | linuxstb | markun: OK - that could be useful. |
19:07:45 | hicks | That would probably explain it then. I'll rebuild using 3.4 |
19:07:48 | markun | linuxstb: If you want, it's at about line 1574 |
19:08:02 | | Quit Shagnar (Remote closed the connection) |
19:08:51 | linuxstb | It depends if we change the codec API. At the moment it only accepts 16-bit, big-endian interleaved samples. |
19:09:02 | hicks | preglow, 3.4.0 or 3.4.4? |
19:09:43 | crwl | i've got 3.4.4 |
19:10:33 | hicks | ok, I'll grab that version. |
19:11:20 | HCl | can the uda output higher than 16bits sound? |
19:11:28 | * | amiconn used rockbox on iriver "for real" the first time |
19:11:42 | linuxstb | I think 20-bits is the limit. |
19:11:49 | HCl | okay |
19:12:11 | linuxstb | I think the DAC can do 24-bit, but there's another bottleneck somewhere (the Coldfire?). |
19:12:55 | crwl | amiconn, i've done that for two days now :) |
19:13:29 | amiconn | I used it in my car, and believe it or not, I still prefer using one of my archoses |
19:13:49 | amiconn | The most annoying thing in the car is the lack of voice ui |
19:16:14 | crwl | i don't do that |
19:16:27 | crwl | i've used it instead of the original firmware mostly because rockbox does gapless |
19:16:34 | crwl | and that's really something :) |
19:16:48 | markun | I just noticed gstreamer has some tag readers for different formats. ape, vorbis, id3 |
19:16:49 | amiconn | Yes it is, definitely |
19:16:55 | preglow | amiconn: well, given the fact that you're an old archos user, that doesn't really surprise me... |
19:16:57 | * | amiconn notices markun |
19:17:25 | amiconn | markun: I read that you didn't understand why menu navigation from the remote wasn't implemented |
19:17:59 | markun | amiconn: was there a good reason? |
19:18:17 | amiconn | There is a reason for this - as the archos remote doesn't have a button to enter the menu, it doesn't make much sense to have menu navigation on the remote |
19:18:38 | markun | Yes, I figured that would be the problem.. |
19:18:46 | amiconn | Your commit has the side effect that it's now possible to navigate the menu on archos too |
19:19:00 | markun | well, now you can at least leave the menu with the remote if you like :) |
19:19:15 | markun | or change some things once you are in, but it's a bit useless.. |
19:20:31 | markun | amiconn: we could remove the defines of the archos remotes again if you think it's better. |
19:20:46 | amiconn | It's not a big problem since the code size increase is minimal though |
19:21:38 | amiconn | It would also be easy to disable remote navigation for the menu - just remove the MENU_RC_* #defines from menu.h for the archos keypads |
19:21:44 | preglow | HCl: i'm sitting on some heavily fixed and updated dumb code |
19:21:53 | markun | I'm not so sure about my button layout for the iriver remote, but it can be changed later. |
19:22:37 | markun | I made 'play' the run button, so keeping it pressed opens the context menu.. |
19:22:45 | HCl | preglow: mm? |
19:22:47 | amiconn | I'm not so sure TREE_RC_RUN was really redundant |
19:22:49 | HCl | from where did that come |
19:22:58 | preglow | from the guy who made the foo_dumb plugin |
19:23:22 | HCl | nice |
19:23:31 | HCl | any floating point things gone? |
19:23:35 | markun | amiconn: I removed TREE_RC_ENTER, but we could put it back if we assign a different key to it. |
19:23:36 | amiconn | It looks like it was, maybe to make it similar to the main TREE_RUN / TREE_ENTER dfines |
19:23:40 | preglow | dont think so, i'll have a look |
19:23:43 | HCl | mk |
19:23:48 | * | HCl goes back to sleep :/ |
19:24:35 | amiconn | markun: The reason for having 2 defines there for the main unit buttons is the Ondio, which only supports one of them |
19:24:48 | markun | amiconn: another thing: the 'center-scrolling' code needs to be implementd in so many cases that I started to wonder if we shouldn't share the code.. |
19:25:08 | amiconn | As long as we don't have to support more different remotes, I think it can stay as it is now |
19:25:38 | markun | It's now in tree.c and menu.c but should also be in playlist_viewer.c |
19:25:46 | markun | can |
19:26:03 | markun | 't we have a generic list browser or something? |
19:27:24 | amiconn | Well, one of the main principles of rockbox is KISS, and a generic list browser would put just another level of abstraction |
19:27:39 | amiconn | It might be very complicated to get it that generic. |
19:28:32 | linuxstb | Is FLAC playback broken for anyone else? It doesn't seem to be buffering enough data - it plays for about a second, then stops to read data from disk, then plays a second.... etc |
19:28:38 | amiconn | There are many special cases, e.g. in the tree browser, there is the partial load for databse browsing |
19:28:48 | markun | Hm, maybe. Also rockboy has a menu.. |
19:29:17 | amiconn | Yes, and rockboy (as some other plugins) should use the core menu functions for that |
19:29:32 | amiconn | linuxstb: FLAC has a performance problem with some files |
19:29:45 | linuxstb | These are the same files that played perfectly in the past. |
19:29:46 | preglow | HCl: there are still floats everywhere |
19:30:01 | HCl | k\ |
19:30:16 | linuxstb | It does look like a buffering problem (from the LED action) |
19:30:19 | preglow | but this one is much more accurate, they say |
19:30:31 | | Quit einhirn (Read error: 131 (Connection reset by peer)) |
19:30:45 | preglow | face it, flac just barely runs |
19:31:48 | linuxstb | But up until today, I had no problems at all. |
19:32:10 | amiconn | markun: I thought about the center scrolling configuration. There are problems with either approach. |
19:32:53 | amiconn | (1) We could set it in percent, but this creates the problem that many values will lead to the same amount of 'line margin' |
19:33:27 | markun | amiconn: I've implemented it now using percents and made it configurable in steps of 10% |
19:33:41 | amiconn | (2) We could also set it in lines (the more logical way imho), but then we need to clamp too high settings in the code, depending on th etotal line count |
19:34:09 | markun | 0% is old behaviour, 100% is center-scrolling. I have it on 80% now. |
19:34:21 | amiconn | The code within each browser function should be just one line per direction |
19:35:12 | markun | I like it this way, do you want to try a patch? |
19:35:30 | markun | as allways it's not finished :) |
19:35:31 | amiconn | When using percent, it might be more logical to allow a range of 0..50 (50 would be center) |
19:36:09 | markun | amiconn: Yes, I thought of that too. Now I devide by 200.. |
19:36:26 | markun | http://130.89.160.166/rockbox/navigation_menu.diff |
19:36:53 | amiconn | I think I should get asm memset() finished, then start working on the graphics api |
19:37:03 | t0mas | 3 days to go |
19:37:03 | t0mas | 19:36:24 up 297 days, 10:21, 0 users, load average: 0.00, 0.00, 0.00 |
19:37:05 | amiconn | asm memcpy() has to wait... |
19:37:23 | t0mas | amiconn: graphics api? |
19:37:59 | *** | Saving seen data "./dancer.seen" |
19:38:17 | t0mas | (have you read my idea about separating the display code?) |
19:40:19 | * | amiconn is still reading up today's log |
19:40:29 | t0mas | k |
19:40:40 | linuxstb | I've changed the ci->configure lines in codecflac to the same as codecwavpack, and that seems to have fixed the problem. |
19:42:42 | | Quit bobTHC ("Smoke Weed Every Day !") |
19:43:22 | hicks | It compiles now, it was because of my gcc version after all. Only problem now is the built rockbox.iriver file hangs on boot showing result: 0 |
19:48:15 | | Join muphicks_ [0] (~hicks@810058c306a5aef0.session.tor) |
19:48:17 | | Nick muphicks_ is now known as hicks2 (~hicks@810058c306a5aef0.session.tor) |
20:00 |
20:03:35 | | Quit hicks (Nick collision from services.) |
20:03:46 | | Nick hicks2 is now known as hicks (~hicks@810058c306a5aef0.session.tor) |
20:07:59 | | Join hardeep [0] (hardeeps@192.94.73.30) |
20:11:16 | amiconn | Plugh_: Still there? |
20:17:38 | | Join Tangleding [0] (~Tangledin@ARennes-351-1-33-189.w82-126.abo.wanadoo.fr) |
20:18:05 | Tangleding | Hello Rockbox |
20:18:08 | | Join hubbel [0] (hubbel@h7n2fls304o1033.telia.com) |
20:19:04 | Tangleding | :) |
20:19:40 | Moos | Hi Tang |
20:20:33 | | Join scriptkitty [0] (~katerina@c-67-176-83-251.hsd1.co.comcast.net) |
20:20:49 | Moos | congratulations for your new H140 ;) |
20:21:16 | t0mas | amiconn: done reading? |
20:22:12 | Tangleding | Thankls Moos |
20:22:28 | Tangleding | i've updated with Rbx just as iv'e received it |
20:22:57 | Moos | good reflexe ;) |
20:23:01 | Tangleding | The Rbx progress is amazing really |
20:23:18 | Tangleding | congratulation to every contributors |
20:23:44 | Tangleding | i'm waiting after my travel to paris |
20:23:56 | Tangleding | but if i have money enough when i come back |
20:24:07 | Tangleding | will be glad to donate another time :) |
20:24:46 | Moos | Paris wait you :) |
20:25:21 | preglow | damn, we gotta find something to do with all this money |
20:25:21 | Tangleding | :)$ |
20:29:56 | t0mas | preglow: pay hosting for rockbox.org? :) |
20:30:19 | t0mas | and buy some more H3xx's for the hardware people |
20:30:36 | bill20r3 | yes |
20:30:38 | Tangleding | do what you want guys |
20:30:40 | Tangleding | :) |
20:30:43 | t0mas | so that port will continue too... and maybe do that with 2 bdm's ? |
20:31:08 | t0mas | so some other core dev can do things with a bootloader too? |
20:31:16 | Tangleding | you have some money loss with all buying: |
20:31:24 | Tangleding | H3xx, H100, |
20:31:37 | Tangleding | next M3, M5 and X5 ;) |
20:31:42 | Tangleding | lol |
20:31:43 | Moos | :) |
20:31:52 | preglow | hosting is sponsored, afaik |
20:32:05 | t0mas | yes, and linus's next volvo? |
20:32:06 | t0mas | ;) |
20:32:12 | preglow | i want a car too :/ |
20:32:20 | * | t0mas wants a license.. |
20:32:23 | t0mas | valid target too? |
20:32:24 | t0mas | :P |
20:32:24 | Moos | ahah :) |
20:32:39 | MO-Pantsu | what codec is .wv? |
20:32:57 | t0mas | 9 months... left... and then noone will ever dare to drive near Gouda again :P |
20:33:21 | amiconn | MO-Pantsu: wavpack |
20:33:37 | MO-Pantsu | ah...supported? or to be supported? |
20:33:44 | MO-Pantsu | I may just convert it otherwise |
20:34:03 | preglow | i've got the license, just need the car |
20:34:14 | preglow | MO-Pantsu: it's supported |
20:34:28 | t0mas | preglow: why not buy a very cheap one? 12th hand? |
20:34:28 | preglow | as of today |
20:34:38 | preglow | t0mas: i will once i move |
20:34:41 | Tangleding | lol Rockbox is planned to be ported on volvo to? |
20:34:43 | MO-Pantsu | cool! you iz fast |
20:34:52 | t0mas | Tangleding: if I get a car for that: yes |
20:35:17 | t0mas | but seriously: Linus was looking at some way to connect his iriver to the volvo sound system |
20:35:24 | t0mas | so maybe he'll find out something intresting |
20:35:52 | Tangleding | :D |
20:35:59 | Tangleding | okay (was joking of course) |
20:36:12 | t0mas | I know :) |
20:36:45 | * | t0mas is bouncing around his room |
20:36:46 | * | t0mas np: Various Artists - Every Single Day (0:24) [http://amarok.kde.org/] |
20:40:55 | | Join Stryke` [0] (~Chairman8@cpe-24-168-110-99.si.res.rr.com) |
20:46:39 | | Join webguest70 [0] (~5087feb1@labb.contactor.se) |
20:48:41 | webguest70 | is R-box's mp3 playback now better than irivers mp3 playback ? |
20:48:52 | Tangleding | better |
20:48:54 | t0mas | it's more accurate |
20:49:00 | Tangleding | i'm checknig if gapless |
20:49:02 | t0mas | but it lags eq |
20:49:03 | Tangleding | if yes |
20:49:08 | t0mas | so no extra bass/treble |
20:49:12 | Tangleding | it will be "Hell YES!!!! |
20:49:53 | webguest70 | hmm, a bit of bass eq would be nice |
20:50:17 | preglow | it's not often gapless |
20:50:22 | | Join xam [0] (xam@2001:770:102:2:201:faff:fe7e:c00d) |
20:50:38 | webguest70 | I've got old ears, need all the help they ca get |
20:50:45 | crwl | it seems to be quite gapless now at least with lame encoded files |
20:51:05 | webguest70 | good all my mp3's are encoded in lame |
20:51:06 | crwl | and i have noticed no more skipping to next track (few hundred milliseconds) too early |
20:51:31 | Tangleding | okay |
20:51:39 | Tangleding | will be quite soon i guess |
20:51:53 | preglow | i tried to make lame gapless work |
20:51:58 | preglow | but something's wrong with libmad |
20:52:06 | preglow | or my code... |
20:52:52 | * | webguest70 hands preglow a frosty beer |
20:53:54 | Tangleding | i see |
20:54:02 | webguest70 | now to see if I can avoid bricking my player :) |
20:54:05 | Tangleding | wish you suceed preglow |
20:54:07 | Tangleding | :) |
20:56:07 | | Quit xam ("Chatzilla 0.9.68.5 [Firefox 1.0.4/20050517]") |
20:56:12 | preglow | haha |
20:56:40 | | Join xam [0] (xam@piranha-fddi.6.strangled.net) |
21:00 |
21:01:52 | Tangleding | ? |
21:04:48 | | Quit webguest70 ("CGI:IRC") |
21:04:56 | | Join webguest70 [0] (~5087feb1@labb.contactor.se) |
21:08:05 | Tangleding | bye all |
21:08:06 | Tangleding | :) |
21:08:11 | | Quit Tangleding ("Chatzilla 0.9.68a [Firefox 1.0.4/20050511]") |
21:17:43 | webguest70 | heh, outstanding, love the file tree browser |
21:18:36 | webguest70 | dir buffer is full ? |
21:19:40 | preglow | large directory? |
21:20:00 | webguest70 | yes 37 gigs worth |
21:20:14 | preglow | yes, there is such a thing as a too large directory |
21:20:19 | preglow | the limit can be raised in preferences |
21:20:26 | webguest70 | ta |
21:21:08 | preglow | general settings>system>limits i guess is the place |
21:21:54 | webguest70 | heh, still trying to figure out how to navigate, need some time |
21:24:32 | webguest70 | upsidedown mode, neat |
21:24:54 | * | HCl is bored :/ |
21:25:54 | | Join DomZ [0] (~52426222@labb.contactor.se) |
21:26:26 | bipak | HCl: hack some new features ;) |
21:29:26 | hicks | HCl your not the HCl from pulltheplug are you? |
21:31:28 | HCl | i am. |
21:31:58 | hicks | Thought it was unusual to see that nick elsewhere :P |
21:32:11 | HCl | heh :p |
21:32:35 | hicks | I was gonna say HCi and see your response instead of asking :P |
21:32:51 | HCl | o.o how would that have helped? :p |
21:32:57 | HCl | i would've said hcL or so |
21:33:12 | | Join thegeek [0] (na@ti521110a080-1100.bb.online.no) |
21:33:17 | hicks | true. |
21:33:23 | HCl | ptp was a long time ago, i'm glad i left that place. |
21:34:17 | hicks | I havn't been there for ages. Used to enjoy playing around on mainsource, but when it went down a few years ago, I never went back. |
21:34:27 | HCl | i see |
21:34:54 | HCl | there's a 486-mainsource-copy under a cabinet in my room, but. i found it too bloody boring to set it back up completely |
21:35:21 | hicks | :) I think I've got all the level solutions on a backup cd somewhere. |
21:35:28 | HCl | hehe :) |
21:38:02 | *** | Saving seen data "./dancer.seen" |
21:39:17 | bipak | is there a .rockbox folder in cvs? |
21:39:42 | bipak | or do i have to copy all necessary files into it? |
21:39:53 | bipak | ..by my self |
21:40:05 | | Quit xam (Read error: 54 (Connection reset by peer)) |
21:40:49 | preglow | do a make zip |
21:40:54 | hicks | bipak, if you're building from cvs do a "make zip" and you'll have a zip with the bin and .rockbox folder |
21:40:56 | preglow | if you're building yourself |
21:41:42 | bipak | ah nice |
21:41:43 | bipak | :) |
21:42:11 | | Join xam [0] (xam@piranha-fddi.6.strangled.net) |
21:42:57 | bipak | can't open dir fonts at /home/bip/tools/rockbox_cvs/rockbox/tools/buildzip.pl line 90. |
21:43:34 | hicks | do you have a fonts dir? If not check out the fonts module from cvs |
21:44:09 | bipak | i have a font dir in the firmware folder |
21:44:24 | bipak | so i think i need the fonts module |
21:44:35 | bipak | cause there is just one bdf file |
21:44:55 | preglow | check out the fonts dir |
21:45:21 | bipak | done :> |
21:45:27 | preglow | now you should be good to go |
21:45:46 | bipak | yep, worked |
21:49:10 | webguest70 | is it possible to delete tracks ? |
21:49:19 | preglow | yes |
21:49:26 | preglow | keep the button pushed and press delete in the menu |
21:49:37 | webguest70 | ta |
21:53:13 | webguest70 | hmm, it can delete whole dir, but I cant see a menu for deleting a single track within a dir |
21:55:27 | webguest70 | cancel that^^, my blindness, am I'm not even drunk |
21:55:35 | webguest70 | yet |
21:55:51 | bipak | :> |
21:56:08 | bipak | nice work, cant say it often enough |
21:57:03 | | Part xam |
21:57:32 | hubbel | someone should tell Motorola to fix Figure 3-5 "Exception Stack Frame Form" in the MCF5249 User's Manual.. It's fucked |
21:58:33 | | Join Pete [0] (~52b65e97@labb.contactor.se) |
21:58:42 | bipak | feel free to do it ;) |
21:59:41 | hubbel | bah, they should have their own proofreaders |
21:59:52 | bipak | hehe :> |
22:00 |
22:03:55 | Pete | how long should a scandisc on iriver ihp 120 take? |
22:06:14 | bipak | is it right that gapless means... to play file after file without any delay? |
22:06:54 | Pete | yeah |
22:08:23 | | Join bipak_ [0] (~bip@p50886BA6.dip.t-dialin.net) |
22:08:27 | bipak_ | re.. |
22:08:33 | bipak_ | got the answer :) |
22:11:07 | | Quit Pete ("CGI:IRC") |
22:11:48 | | Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) |
22:12:16 | preglow | hubbel: it's not the first erronous part of the manual i've seen |
22:12:28 | HCl | mrf |
22:12:54 | webguest70 | the pop between track selections is quite loud |
22:13:37 | preglow | yes |
22:13:39 | preglow | we know |
22:13:53 | preglow | hubbel: so, what's up with recording? |
22:16:57 | hubbel | preglow: i've got dma working |
22:17:40 | preglow | and it's working well? |
22:18:12 | hubbel | preglow: One small glitch but I think I've found it now |
22:18:48 | preglow | do you know if we can have full duplex audio, btw? |
22:18:53 | hubbel | linus had an error in the default interrupt function, which was supposed to tell which interrupt really occured - but it masked the wrong bits |
22:19:08 | hubbel | preglow: yes, it should be possible |
22:19:24 | hubbel | preglow: like time-shifted recording/playback =) |
22:19:43 | preglow | i'm thinking about realtime special effects, heh |
22:19:59 | hubbel | hum.. it would be cool to make realtime vocoder or some darth-vader filter =) |
22:20:05 | bipak_ | lol :D |
22:20:55 | preglow | yes |
22:21:06 | preglow | i'm still thinking about the vocoder, heh |
22:21:14 | HCl | hehe |
22:21:27 | hubbel | realtime pitch change filter is cool |
22:21:50 | Plugh_ | amiconn: I'm here |
22:21:52 | preglow | yeah, that shouldn't be too hard either |
22:22:24 | Plugh_ | amiconn: you have some input on my vbr probs? |
22:22:47 | HCl | heheh. sweet. |
22:23:05 | HCl | my university is gonna upgrade from 1gbit to 10gbit within this year |
22:23:22 | preglow | haha |
22:23:24 | preglow | what necessity |
22:23:27 | markun | HCl: what a nice university you have :) |
22:23:27 | HCl | :P |
22:23:30 | HCl | markun: :p |
22:23:37 | preglow | i already have over 10gbit, though |
22:23:46 | preglow | can't remember how much |
22:24:03 | preglow | that is, _i_ only have 100mbit :/ |
22:24:51 | HCl | *nods* |
22:24:55 | markun | just found out the metadata in wavpack is apev2. fb2k writes replaygain info to mp3 files also in apev2. |
22:25:05 | HCl | we can have 100mbit per computer, multiple computers = more. |
22:25:12 | HCl | with a maximum of 300mbit per flat |
22:25:42 | | Quit bipak (Read error: 110 (Connection timed out)) |
22:25:58 | preglow | haven't tried that |
22:26:02 | preglow | depends on the switch ports, i guess |
22:26:12 | preglow | i've only got one ethernet socket |
22:26:23 | preglow | there's another one in the kitchen, though |
22:26:23 | preglow | hmm |
22:27:02 | preglow | so i guess there's a theoretical maximum of 400mbit per flat here |
22:27:15 | HCl | :) |
22:27:29 | preglow | i shall leech like a mad man the days before i move |
22:27:31 | * | HCl goes to try his gta mission again.. |
22:27:33 | HCl | hahahah. |
22:27:40 | HCl | then it'll be too late :) |
22:27:43 | HCl | leech now, burn on dvd :) |
22:27:46 | preglow | no time now |
22:27:50 | HCl | why not? |
22:27:51 | preglow | haha |
22:27:53 | preglow | lots of disk space |
22:28:02 | preglow | need to boot windows to leech, can't work in windows |
22:28:21 | preglow | laundrybrb |
22:28:21 | HCl | http://surfstat.surfnet.nl/surfstat/lokaal/totoctets.cgi?klant=utwente |
22:28:25 | HCl | look at the bottom pic there |
22:28:30 | HCl | total stats of our university over time |
22:29:01 | HCl | even though we're well under 800mbit, the administator person of our isp says it "warranted an upgrade to 10gbit" :P |
22:29:52 | HCl | all because we hit the 1gbit flatline earlier this week :p |
22:30:05 | HCl | our university ftp server pulled 850mbit on its own :P |
22:30:12 | hubbel | Another error in MCF5249 UM, there's no bit in INTERRUPTEN or INTERRUPTEN3 to enable/disable PDIR3UNOV (int 0x56) |
22:30:15 | * | HCl has root access on that thing :) |
22:34:08 | webguest70 | I have pasted wps code to a .text file, can I put that in .rockbox's dir ? |
22:34:19 | Stryke` | change the extension to .wps |
22:34:31 | webguest70 | ta |
22:34:38 | Stryke` | then place it in .rockbox |
22:37:59 | | Join yngwi [0] (~chatzilla@chello080109107064.1.15.vie.surfer.at) |
22:38:08 | yngwi | hi all |
22:39:54 | HCl | hello |
22:40:32 | yngwi | today i had my h140 out with me and rockbox running... worked great, had to reset only once.. :-) |
22:40:56 | Bagder | Wear Your Pin (tm) |
22:40:58 | Bagder | ;-) |
22:41:02 | yngwi | the first "real life" test |
22:41:35 | yngwi | yeah, i have a special "pencil" don't know the word, which fits into the reset hole |
22:42:13 | yngwi | "propelling pencil" |
22:42:19 | preglow | HCl: http://www.pvv.ntnu.no/~thomj/rockbox/dumb-k54-2005-06-13.tar.gz |
22:42:26 | preglow | HCl: strongly enhanced version of dumb |
22:42:50 | preglow | i just used a piece of wood i found |
22:42:56 | yngwi | hehe |
22:43:31 | MO-Pantsu | FF is still broken on MP3. Someone wanna let Miika know? :) |
22:43:43 | preglow | broken how? |
22:43:50 | yngwi | it sounds really good, besides the known problems :-) |
22:44:05 | MO-Pantsu | it still thinks the track has finished before it has if you FF |
22:44:36 | MO-Pantsu | if you FF to near end of some tracks it ends the track prematurely |
22:44:41 | preglow | that isn't the bug he fixed today |
22:44:44 | MO-Pantsu | oh ook |
22:44:57 | preglow | everything that has to do with track length is really shady thus far |
22:44:57 | Slasheri | MO-Pantsu: yep, i found that problem just recently when i was testing track flushing and reloading |
22:45:19 | preglow | i don't even know where codecmpa gets it's current tracklength from |
22:45:27 | preglow | unless it's got a lame header |
22:45:58 | markun | where do we want to do all the tag reading? |
22:46:03 | MO-Pantsu | Yeah I was testing the gap between tracks and found it's jumping ahead before the track ends so have to listen to the entire track to test that |
22:47:24 | preglow | seeking is not very accurate |
22:47:28 | preglow | known behaviour, etc, lol |
22:47:34 | Slasheri | markun: Hmm, something called metadata.c or similar might be good place :) |
22:48:04 | preglow | but yeah, do we want rockbox to have loaders for all metadata types? |
22:48:24 | preglow | it's not that bad an idea, really, there aren't THAT many metadata types |
22:48:55 | Slasheri | preglow: codecs could read the metadata but that will cause problems to the next track display etc. |
22:48:56 | linuxstb | Yes, I think it should just be one function - e.g. "get_metadata" that gets called for every type of file. |
22:48:59 | markun | id3, id3v2, apev1, apev2, vorbicomment? |
22:49:33 | markun | does mpc still use apev1? |
22:49:45 | preglow | apev2, i guess |
22:49:45 | Stryke` | apev2 |
22:55:10 | markun | Should the metadata of a file be read when it's added to the playlist? |
22:55:26 | Bagder | playlist? |
22:55:37 | Bagder | it should be read when loaded into the audio buffer |
22:55:48 | Bagder | if it should work like existing rockbox |
22:56:07 | linuxstb | Or earlier if the first track is larger than the audio buffer. Otherwise we have no "next track" info. |
22:56:28 | Bagder | right, but that's a limit we've accepted |
22:56:48 | Bagder | so next track info only appears when we actually have that info around |
22:56:56 | linuxstb | I don't feel strongly about it. My WPS doesn't even contain the next track... |
22:57:12 | Bagder | rather common for Archos' 1.6MB buffer ;-) |
22:57:13 | preglow | i don't care either |
22:58:04 | preglow | linuxstb: that resampler thread quickly evolved away from our needs ;) |
22:58:24 | linuxstb | preglow: That's linux-audio-dev for you - we were lucky to get two or three on-topic replies. |
22:59:29 | linuxstb | They've spent the last week discussing compilers... |
22:59:52 | preglow | i wonder how picky people are about resamplers |
23:00 |
23:00:04 | preglow | perhaps a simple linear interpolator will do for other resampling as well... |
23:00:32 | linuxstb | I think we should just get something working - it's easy to improve later. |
23:00:34 | Bagder | seems clever to at least start with the easy way |
23:01:13 | preglow | indeed |
23:02:01 | linuxstb | We need to agree on the format codecs will give Rockbox the uncompressed data in. A common format, or their own format? |
23:02:03 | preglow | i wonder how large buffers we'll ever need |
23:02:25 | preglow | their own format plus a shifting coef would be nice |
23:02:35 | preglow | hmm |
23:02:36 | preglow | then again |
23:03:31 | linuxstb | It seems easier to do it the way we do now - possibly with the exception of mono->stereo conversion. |
23:04:32 | preglow | and all the other processing we need to do |
23:06:21 | preglow | i don't we'll win much apart from code duplication if we keep such processing in the codecs |
23:06:26 | preglow | i don't think, even |
23:08:17 | linuxstb | But every codec's different. |
23:09:01 | linuxstb | But I am almost convinced. |
23:09:04 | preglow | in what regards? |
23:09:15 | preglow | a lot of them share the fact that they serve data in 32 bit ints, noninterleaved |
23:09:20 | preglow | so they have to interleave in the codec now |
23:09:30 | preglow | if we ever get replaygain support, they all need to gain their data |
23:09:32 | preglow | and eq it |
23:10:28 | preglow | the only notable difference is data type size and interleavedness, imho |
23:10:31 | | Join looksaus [0] (~looksaus@dD577C354.access.telenet.be) |
23:10:48 | hubbel | This is unreal.. I've get a crash when I write "Done" to DSR1 in my DMA1 handler (recording).. This works fine in the DMA0 handler (playback).. I've double-checked the address of DSR1 and I can read out the status without problem |
23:11:25 | preglow | perhaps this is why iriver uses interrupts ;) |
23:12:47 | hubbel | The thing is if I use DMA without the interrupt-when-finished feature, it works fine, but you don't know exactly when the transfer has finished |
23:16:14 | Slasheri | i managed to fix the seeking problem :) |
23:16:21 | Slasheri | now testing flushing |
23:16:21 | preglow | Slasheri: leetness |
23:16:33 | Slasheri | :P |
23:16:35 | preglow | have you tested playing silence between track changes, btw? :PP |
23:16:45 | preglow | that click after skipping a track is my last major annoyance |
23:16:50 | Slasheri | no i havent :) |
23:17:13 | Slasheri | Hmm.. I don't get any click when track changes.. |
23:17:23 | hubbel | preglow: aaaaaaaaa |
23:17:27 | hubbel | preglow: now it works! |
23:17:30 | Slasheri | With mp3 if the track contains some silence |
23:17:48 | preglow | hubbel: what wrong? |
23:17:49 | hubbel | preglow: changed DSR = 1 to DSR |= 1 |
23:18:00 | hubbel | DSR1 |
23:18:16 | preglow | Slasheri: you dont? i get clicks at the start of all tracks |
23:18:44 | DomZ | i can confirm this :) |
23:18:48 | Slasheri | preglow: ah, yes with skipping.. Now i got a very small near unhearable click |
23:18:57 | preglow | near unhearable? |
23:19:00 | preglow | mine clicks like mad |
23:19:06 | Slasheri | hmm :/ |
23:19:14 | DomZ | not too much for me |
23:19:21 | preglow | i'm convinced it's dc |
23:19:25 | preglow | can't think of anything else |
23:20:43 | markun | I have the same problem. You don't get the click if you skip during silence |
23:21:51 | preglow | well, of course not, if the dac holds a zero you wont hear anything |
23:21:57 | preglow | if it holds a non-zero sample, though |
23:22:09 | | Quit Chamois (" HydraIRC -> http://www.hydrairc.com <- IRC for those that like to be different") |
23:22:11 | preglow | linuxstb: your oasis ac3 skips like mad now, btw |
23:22:35 | markun | yes, it was my proof for the dc theory |
23:22:44 | looksaus | is anyone toying with FLAC support on the iRiver-iHP1x0? |
23:23:13 | Bagder | looksaus: it is already there |
23:23:14 | preglow | looksaus: toying? it's already supported |
23:23:19 | looksaus | it seems all kinds of things are moving around it, but the progress is somewhat scarcely documented |
23:23:24 | looksaus | nice! |
23:23:29 | | Quit matsl (Remote closed the connection) |
23:23:36 | preglow | well, the wiki says it's supported |
23:23:42 | linuxstb | http://www.rockbox.org/twiki/bin/view/Main/SoundCodecs#Current_status |
23:23:42 | looksaus | is there a battery life comparison somewhere? |
23:23:43 | preglow | that's pretty much all the documentation you're going to see |
23:23:57 | looksaus | preglow, sorry, I read the FAQ and the main page |
23:24:57 | preglow | but yeah, read the url linuxstb pasted, there you've got all the file formats we currently support |
23:25:13 | looksaus | hey, this is really nice |
23:25:18 | preglow | agreed |
23:25:18 | looksaus | ! |
23:25:48 | looksaus | so, any comparisons of battery life with the original firmware versus rockbox on the iHP-120? |
23:26:03 | preglow | none really official, no |
23:26:10 | preglow | anyone know what solid ended up on for vorbis? |
23:26:14 | linuxstb | preglow: I think the oasis ac3 skipping is just buffering problems - it looks like the buffer is becoming empty. |
23:26:29 | preglow | linuxstb: it didn't skip yesterday |
23:26:41 | | Join ashridah [0] (ashridah@220-253-123-30.VIC.netspace.net.au) |
23:26:42 | linuxstb | And neither did my FLACs |
23:27:01 | looksaus | preglow, WOW!! someone is working on MIDI on the iRiver thing? |
23:27:21 | preglow | looksaus: yes |
23:27:26 | looksaus | sorry if I sound so excited, but as a music teacher, this is REALLY great news |
23:27:40 | preglow | it's even working |
23:27:44 | preglow | but it's too slow at the moment |
23:27:59 | bill20r3 | heh |
23:28:00 | preglow | and the author wont have time to hack at it for a little while |
23:28:03 | bill20r3 | mod files are next |
23:28:15 | looksaus | pity... |
23:28:19 | preglow | looksaus: you're seldom required to apologize for enthusiasm here ;) |
23:28:35 | preglow | yes, indeed, but such is life |
23:28:39 | ashridah | heh, the midi module will be a pain to buffer in with other music |
23:28:45 | preglow | not really |
23:29:00 | ashridah | preglow: well, given the potential size of the wave table |
23:29:08 | preglow | the buffer will just have to be flushed sooner than usual in worst case |
23:29:40 | * | HCl prods Slasheri |
23:29:52 | linuxstb | preglow: Increasing the size of FILEBUF_CHUNKSIZE in the codeca52 fixes the oasis problem. |
23:29:53 | Slasheri | HCl: Not done yet ;) |
23:30:16 | Slasheri | HCl: I am trying to get seeking & flushing working |
23:30:20 | | Quit gromit` (Remote closed the connection) |
23:30:24 | preglow | looksaus: but yeah, don't hold your breath on midi, there's a lot of work to be done for that kind of file yet, and we're still not done with ordinary music playnack |
23:30:30 | preglow | it'll get done, though |
23:32:13 | looksaus | hm, I'm just discovering rockbox and asking about things that are probably out of reach, but still... |
23:32:16 | HCl | ;p okay :) |
23:32:20 | HCl | thats fine |
23:32:25 | HCl | i was just wondering whether you had forgotten or not :) |
23:32:57 | looksaus | would it be possible to do something like gstreamer's speed plugin does |
23:33:18 | Slasheri | HCl: i will do it tomorrow if i have some time :) |
23:33:21 | looksaus | like, slowing some music down a little |
23:33:22 | HCl | k :) |
23:33:31 | HCl | no idea |
23:33:44 | preglow | looksaus: 'course |
23:33:46 | HCl | do we have the power to resample to change pitch and stuff? *looks at preglow* |
23:33:51 | | Quit Harpy (Read error: 145 (Connection timed out)) |
23:34:04 | looksaus | I saw pitch mentioned |
23:34:05 | preglow | looksaus: depends on if you want pitch to be changed or not |
23:34:32 | looksaus | pitch: no, speed: yes |
23:34:43 | preglow | that's time stretching, it's not trivial, but can be done |
23:34:45 | looksaus | sorry if I'm asking dumb questions |
23:34:49 | preglow | nono |
23:35:18 | preglow | i might look at it once, since that's more my area of interest |
23:36:50 | looksaus | heh |
23:36:58 | looksaus | would be nice :) |
23:37:01 | preglow | deed |
23:37:48 | looksaus | enjoy hacking on rockbox... I'm off to sleep |
23:38:03 | *** | Saving seen data "./dancer.seen" |
23:38:12 | | Part looksaus ("Bezig met verlaten") |
23:40:16 | HCl | heh o.o. |
23:41:51 | preglow | ahahah |
23:42:01 | preglow | the uda's headphone output isn't decoupled |
23:42:06 | preglow | small wonder we get pops and clicks, then |
23:44:21 | hubbel | preglow: hm.. did I forget to set some UDA register to compensate for that? |
23:45:09 | hubbel | hum.. Speex project looks interesting.. wonder if it can encode in realtime |
23:45:16 | | Quit tvelocity (Read error: 60 (Operation timed out)) |
23:46:21 | preglow | hubbel: only thing i can think of the uda driver can do, is mute and unmute the digital part before any other parts are powered up/down |
23:46:31 | preglow | as described in 8.12 in the data sheet |
23:46:47 | preglow | right now every part of the uda is initalisied at once, i think |
23:47:19 | | Join gromit` [0] (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net) |
23:47:33 | hubbel | preglow: ok, going to try the 8.12 stuff later |
23:50:40 | | Join courtc [0] (~courtc@adsl-158-35-74.asm.bellsouth.net) |