| 00:10:51 | | Join jacobk [0] (~quassel@utdpat242026.utdallas.edu) |
| 00:25:40 | | Quit othello7 (Ping timeout: 276 seconds) |
| 00:32:26 | | Quit jacobk (Ping timeout: 245 seconds) |
| 00:44:35 | | Join jacobk [0] (~quassel@64.189.201.150) |
| 00:56:07 | | Quit LjL (Read error: Connection reset by peer) |
| 00:56:39 | | Join LjL [0] (~ljl@user/ljl) |
| 01:00 |
| 01:18:11 | *** | Saving seen data "./dancer.seen" |
| 01:18:17 | | Quit pixelma (Quit: .) |
| 01:18:17 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 01:19:15 | | Join pixelma [0] (marianne@p200300ea87138500305e95fffec66ff3.dip0.t-ipconnect.de) |
| 01:19:15 | | Join amiconn [0] (jens@p200300ea87138500305e95fffec66ff3.dip0.t-ipconnect.de) |
| 01:21:15 | | Quit davisr (Remote host closed the connection) |
| 01:25:47 | | Quit ddevault (Changing host) |
| 01:25:47 | | Join ddevault [0] (e7b4bb6755@sourcehut/staff/ddevault) |
| 01:36:30 | | Join IPG [0] (~InvoxiPla@176.25.14.149) |
| 01:59:36 | | Join aaabbb [0] (sitku@bitcoinshell.mooo.com) |
| 02:00 |
| 02:39:24 | | Join termac [0] (~termac@user/termac) |
| 02:39:42 | | Quit jacobk (Ping timeout: 268 seconds) |
| 02:51:21 | aaabbb | how active is rockbox development? |
| 03:00 |
| 03:18:15 | *** | Saving seen data "./dancer.seen" |
| 03:24:38 | termac | there are people working on it |
| 03:24:45 | termac | https://git.rockbox.org/cgit/rockbox.git/log/ |
| 03:25:38 | aaabbb | cool |
| 03:38:53 | termac | i got a question regarding the hifi walker h2, not related to rockbox itself: when i connect my headphones i have a static background noise and i need to set the volume very low like 10/100 or lower |
| 03:40:37 | termac | is there something on the player i can adjust to make it work better with these headphones or do i need to add extra resistance between the player and the headphones |
| 03:42:07 | termac | earphones are these: https://pubs.shure.com/guide/SE215/en-US#u_4e86b4be-de8c-4063-8d7d-0c9da2a405f5 |
| 03:54:26 | | Join tm512 [0] (~tm512@user/tm512) |
| 03:57:41 | | Join ac_laptop [0] (~ac_laptop@2001:910:107e:1:e29d:31ff:fe2d:a258) |
| 03:58:33 | | Join jacobk [0] (~quassel@129.110.242.173) |
| 04:00 |
| 04:16:27 | tm512 | kinda seems like the Sansa devices are some of the best rockbox-capable devices on a budget? been thinking of picking up an MP3 player to play around with, just don't want to spend that much on something that does only a subset of what my phone already does |
| 04:17:24 | jssfr | I'm pretty happy with the sansa family, yes |
| 04:17:45 | jssfr | audio quality is decent, they have physical buttons, a microsd slot, and that's good in my book. |
| 04:17:49 | tm512 | I have quite a bit of nostalgia for MP3 players though, was in high school when they were still massively popular, probably more common than smartphones |
| 04:19:56 | | Quit jacobk (Ping timeout: 245 seconds) |
| 04:20:26 | tm512 | what's the battery situation like on these older Sansa devices nowadays? |
| 04:20:57 | jssfr | holds up for several days of occasional use, certainly for 10+ hours |
| 04:21:10 | jssfr | also, I have a USB-C->A adapter for my phone, which allows me to charge the sansa from the phone :-) |
| 04:23:03 | tm512 | a quick google search brought up this and the use of papyrus as a font on the packaging certainly inspires confidence /s https://www.amazon.com/NewPower99-SanDisk-Sansa-Fuze-Installation/dp/B008MZM68E |
| 04:23:50 | jssfr | the batteries are also soldered, which is ... not fun |
| 04:23:56 | jssfr | easy to short while unsoldering the wires |
| 04:23:58 | jssfr | at least in some models |
| 04:26:11 | * | tm512 does not even have a soldering setup |
| 04:26:38 | tm512 | maybe that's something I should change |
| 04:31:27 | tm512 | looks like the NOMAD Jukebox ZEN has replacable batteries and if I'm not mistaken, 2.5" HDDs are basically non-flash CompactFlash cards. seems like the perfect device, though it doesn't look like rockbox supports those? |
| 04:32:59 | tm512 | or wait, not 2.5", the 1.3" ones or whatever |
| 04:34:44 | tm512 | wikipedia says those use 2.5" drives but those devices don't look *that* large. but I dunno |
| 04:34:48 | jssfr | 1.3" HDDs are hard to come by *and* you cannot just swap an SSD in |
| 04:34:58 | | Quit CH23_M (Ping timeout: 256 seconds) |
| 04:35:02 | jssfr | I did that with my iriver and it fried the power regulation system because the SSD needed more amps |
| 04:35:10 | jssfr | my iriver also didn't like a CF adapter unfortunately |
| 04:35:32 | | Join CH23_M [0] (~CH23@revspace/participant/ch23) |
| 04:37:58 | tm512 | does seem like the 1.3" HDDs are the exact same form factor as a CF card, both using an IDE interface as well. dunno about the power consumption. the thought of flash memory drawing more power than an HDD seems odd to me |
| 04:38:09 | jssfr | oh it's not odd |
| 04:38:14 | jssfr | I've got several instances of that, in fact. |
| 04:38:45 | jssfr | I have three 2.5" disks in my home lab: a HDD (500mA peak), and two SSDs (1A and 1.5A peak) |
| 04:38:58 | jssfr | flash needs high currents for write operations IIRC |
| 04:39:21 | jssfr | while HDDs only need high currents for spinup, and that can be brought down by spinning up at a lower rate, which low-RPM drives (as commonly found in small form factors) generally do. |
| 04:42:07 | tm512 | are you including CF cards as SSDs? I know they're all flash memory, and "solid state", but I thought the type of flash could differ drastically, with memory cards typically being a sort that is way less durable |
| 04:42:34 | | Join jacobk [0] (~quassel@64.189.201.150) |
| 04:43:15 | jssfr | CF cards didn't work at all in my device so I haven't tried it. |
| 04:43:36 | jssfr | I guess for CF you can find the maximum current numbers in some specification and compare that to the numbers on the HDD you aim to replace. |
| 04:47:48 | tm512 | not sure which devices I'd even consider that use a microdrive and support rockbox, the iPod Classics seem on the pricier end |
| 04:48:01 | tm512 | at least the newer ones, like 5G and up were what I looked at |
| 04:48:41 | tm512 | like easily >$100 whereas I could get a Sansa for under $50 and get a microSD slot with the latter |
| 04:50:29 | tm512 | I guess I'd just worry about the battery when/if it becomes an issue, maybe send it and a new battery to someone with actual soldering skills to perform the replacement |
| 04:50:50 | jssfr | sounds reasonable |
| 05:00 |
| 05:10:01 | tm512 | another thing I was curious about. do codecs make a significant difference on battery life on most players? like the impression I've gotten is that musepack has about the best compromise between compression efficiency and computational complexity, though if it doesn't matter much I'd probably just use opus in cases where I'm making my own encodes from lossless |
| 05:11:50 | jssfr | I do know that opus (used to be) more complex than e.g. vorbis; while my iriver was able to decode vorbis in realtime without clock frequency boosts, opus required those. |
| 05:12:15 | jssfr | I'm not sure what the current situation is, I assume that there has been some optimization. |
| 05:12:52 | aaabbb | the libopus decoder has significantly improved |
| 05:12:59 | aaabbb | but it's still heavier than mp3 |
| 05:17:07 | tm512 | assuming an SoC that can handle it, would it make much of a difference on battery life over a cheaper codec? |
| 05:18:16 | *** | Saving seen data "./dancer.seen" |
| 05:22:51 | aaabbb | is this solid state or spinning? |
| 05:24:10 | aaabbb | tm512: https://www.rockbox.org/wiki/CodecPerformanceComparison |
| 05:24:32 | tm512 | the Sansa e200 series (which I'm looking at) is all flash |
| 05:25:32 | aaabbb | so mp3 decoding is much more efficient on that than musepack |
| 05:27:34 | aaabbb | at least on your hardware |
| 05:28:54 | | Quit CH23_M (Ping timeout: 260 seconds) |
| 05:29:24 | tm512 | aaabbb: at 96kbit it seems MP3 has a big advantage but it looks like they get closer at higher bitrates |
| 05:30:46 | tm512 | I'm not sure exactly what the MHz values on this table is actually representing |
| 05:31:23 | aaabbb | that's clock frequency needed for realtime play |
| 05:31:35 | jssfr | (theoretically, I guess) |
| 05:31:43 | aaabbb | yeah, roughly |
| 05:31:48 | jssfr | because I doubt that the clip can go to ~1 GHz :D |
| 05:32:19 | aaabbb | well it means that's what it would have to go to in order to achieve realtime |
| 05:32:38 | aaabbb | whether the hardware can hit the required frequency is another question... haha |
| 05:32:57 | jssfr | I mean, briefly it probably can. |
| 05:32:58 | tm512 | the v1 e200 apparently has two 80MHz ARM7TDMI cores |
| 05:33:13 | tm512 | and the v2 has a 250MHz ARM9TDMI |
| 05:33:51 | aaabbb | jssfr: i doubt it would even recognize a 1ghz signal as a clock signal |
| 05:34:14 | aaabbb | tm512: which version do you have? |
| 05:34:23 | aaabbb | and does rockbox have any way to utilize the two core anyway? |
| 05:35:18 | tm512 | aaabbb: I don't have one (yet) |
| 05:37:39 | tm512 | I was thinking of picking one up. I dunno if I care much whether it's the older ARM7 one or the ARM9. seems anything other than HE-AAC would be handled just fine on the ARM7 |
| 05:38:46 | aaabbb | arm9 has tcm. idk if rockbox makes use of the tcm, but if it does, it should allow significant performance improvements for codecs that don't require much memory |
| 05:38:51 | aaabbb | IF it use the tcm |
| 05:38:55 | tm512 | though these results are quite old, 2010, dunno if the situation has changed, but I don't think I have any HE-AAC stuff laying around, nor do I have much of a reason to make copies with that codec |
| 05:39:53 | aaabbb | xHE-AAC isi a wonderful codec, slightly more efficient than opus at low bitrates |
| 05:40:02 | aaabbb | not regular HE-AAC tho :) |
| 05:48:21 | tm512 | looking at these results though it seems like musepack would be a reasonable choice for cases where I'm not starting with a mid-low bitrate source |
| 05:49:17 | aaabbb | since they're so close at mid-high bitrates, i'd care more about the audio quality of those codecs |
| 05:52:52 | | Quit termac (Ping timeout: 255 seconds) |
| 05:54:43 | | Join termac [0] (~termac@user/termac) |
| 05:55:52 | tm512 | mpc is supposed to be transparent around 160-192kbit but I guess even at 128kbit, it gives vorbis a run for its money. opus would still be better, if it doesn't noticeably affect battery life |
| 05:56:28 | aaabbb | opus is something like 30% heavier than vorbis if i remember |
| 05:56:31 | aaabbb | it used to be over double |
| 06:00 |
| 06:04:12 | tm512 | I'll have to do some ABX tests on myself, because if I end up being unable to reliably tell the difference between opus and mpc at the bitrates I plan on using, even with my headphone setup, then I'm better off just using the cheaper codec |
| 06:04:46 | tm512 | certainly wouldn't be able to tell the difference with the Sansa's DAC and headphones that I actually feel comfortable taking out of the house |
| 06:05:32 | aaabbb | just because you can't ABX one sample doesn't mean you can ABX another. idk how mpc works but with opus, it may be nearly transparent, but then suddenly go into intensity stereo which you may n otice |
| 06:06:33 | tm512 | also it's a bummer these devices don't have bluetooth support, because nowadays using a bluetooth speaker is perhaps the most common use I have for mobile audio playback |
| 06:06:54 | | Quit sch (Ping timeout: 268 seconds) |
| 06:07:11 | aaabbb | bt reduces audio quality because it reencodes to a different lossy format, so there's some generation loss |
| 06:11:58 | tm512 | I don't think it really matters considering the quality of the bluetooth speaker I have, which if I had to be kind to it all I could say is "it's better than not having music" |
| 06:19:55 | | Quit termac (Ping timeout: 276 seconds) |
| 06:19:58 | tm512 | I figure if that use case really matters with this device I'd just pick up a bluetooth transmitter. though passing the analog output from the MP3 player into a cheap ADC for further lossy encoding is not ideal especially if I got a better speaker or decent wireless headphones |
| 06:23:32 | tm512 | I could, perhaps, just look for a portable speaker with an analog input |
| 06:36:47 | | Join tricky [0] (~tricky@2600:6c48:503f:4550::9019) |
| 07:00 |
| 07:18:17 | *** | Saving seen data "./dancer.seen" |
| 07:25:08 | | Quit tricky (Quit: Leaving) |
| 09:00 |
| 09:18:18 | *** | Saving seen data "./dancer.seen" |
| 10:00 |
| 10:02:34 | | Join dconrad_web [0] (~dconrad_w@184.170.163.35) |
| 10:06:15 | dconrad_web | termac: the h2 definitely has a relatively hot output, and those se215s look to be pretty sensitive. I have noticed a small amount pf background noise on my player when using sensitive IEMs like that in a very quiet room, but nothing that you would notice with even quiet audio playing |
| 10:08:39 | dconrad_web | if I recall correctly, the noise doesn't scale with volume though - you may want to try with some different headphones and see if those are better? |
| 10:10:05 | dconrad_web | could also try an attenuator too, there used to be one specifically intended for iems, but I'm not sure if its still for sale. I seem to recall it was kind of expensive for what it was too |
| 10:26:07 | | Quit dconrad_web (Quit: Connection closed) |
| 10:32:51 | | Join othello7 [0] (~Thunderbi@pool-100-36-166-8.washdc.fios.verizon.net) |
| 10:48:58 | | Quit Maxdamantus (Ping timeout: 255 seconds) |
| 10:49:38 | | Join Maxdamantus [0] (~Maxdamant@user/maxdamantus) |
| 11:00 |
| 11:18:19 | *** | Saving seen data "./dancer.seen" |
| 11:18:29 | speachy | tm512, jssfr: FWIW, the iriver devices work with CF just fine, but you need the latest bootloader and a nightly build newer than the 3.15 release. |
| 11:18:44 | speachy | the OF doesn't work at all with CF cards though. |
| 11:20:14 | speachy | the high write currents of "flash" devices are heavily skewed by mSATA and nvme stuff that has high write speeds. CF cards are much lower power, and SD cards are lower yet |
| 11:21:09 | speachy | (And consider that the spin-up current is awful, and applies wthether it's a read or write operation) |
| 11:22:35 | | Join sch [0] (a2fe4b5ecb@irc.cheogram.com) |
| 11:24:46 | speachy | aaabbb: on a typical port, TCM/IRAM is used for the most performance critical code, and yes, that includes parts of some of the codecs. At least the ones that we've tuned, anyway. |
| 11:27:27 | speachy | also, wrt codecs and their theoretical quality, consider that the analog stage of most of these DAPs isn't all that great, and unless you have golden headphones (and ears) you'd be hard pressed to tell the difference in the real world. Also, IME the actual CPU core is only a minority of the overall powre consumption. The analog path (poer supplies, headphone amp, clocks/PLLs that are always |
| 11:27:29 | speachy | running whenever something is playing back.. that's the main power draw. |
| 11:27:56 | speachy | (storage and the screen also tend to completely dwarf the actual CPU) |
| 11:28:42 | speachy | a while back I implemetned dynamic reclocking for the jz47xx targets, from ~540MHz down to under 200. The difference wasn't measurable in the battery benchmark. |
| 11:39:53 | speachy | (ie on the order of a minute or two across a >12 hour test...) |
| 12:00 |
| 12:09:51 | | Join davisr [0] (~davisr@fsf/emeritus/davisr) |
| 13:00 |
| 13:18:20 | *** | No seen item changed, no save performed. |
| 13:41:46 | | Quit jacobk (Ping timeout: 255 seconds) |
| 13:48:05 | | Join lebellium [0] (~lebellium@2a01cb040610e0000dad3812425e164a.ipv6.abo.wanadoo.fr) |
| 13:51:43 | | Join termac [0] (~termac@user/termac) |
| 13:53:41 | | Join jacobk [0] (~quassel@129.110.242.224) |
| 13:59:27 | | Quit davisr (Remote host closed the connection) |
| 14:00 |
| 14:00:04 | | Join davisr [0] (~davisr@fsf/emeritus/davisr) |
| 15:00 |
| 15:18:24 | *** | Saving seen data "./dancer.seen" |
| 16:00 |
| 16:01:52 | | Quit jacobk (Quit: No Ping reply in 180 seconds.) |
| 16:03:30 | | Join jacobk [0] (~quassel@129.110.242.224) |
| 16:47:18 | tm512 | speachy: wow I would have expected reclocking to make some kind of difference at least. I guess I'll probably end up opting for opus |
| 16:54:26 | speachy | older stuff is more power hungry at the CPU core level, but yeah, that surprised me too. |
| 16:54:44 | tm512 | quality of a codec is only a minor consideration. I'd take a "worse" codec for improved battery life, since regardless of what I pick I'll probably be using similar bitrates, though opus will probably provide more headroom for maintaining transparency even with difficult sections of music |
| 16:55:50 | tm512 | like I'd probably use opus at 160kbit or 192kbit, unless my listening tests show some inadequacy there, but I kinda doubt it |
| 16:56:16 | speachy | opus is pretty hard to beat honestly. |
| 16:56:53 | | Quit Malinux (Ping timeout: 240 seconds) |
| 16:57:10 | tm512 | I spent almost $500 on a headphone setup (DAC/amp + headphones) years ago and to my ears it was only a moderate improvement over my previous headphones going through onboard DACs/amps |
| 16:57:16 | speachy | mp3 is still quite good at ~128k, and low CPU load. most of the argument for higher compresson codecs is to use less disk space/bandwidth but that's honestly not much of an issue |
| 16:57:17 | tm512 | I definitely don't have golden ears |
| 16:57:46 | speachy | hah, yeah, and even if you had golden years once, age is relentless. :D |
| 16:59:04 | tm512 | I was honestly surprised by LAME @ 128kbit from a lossless source. totally inconsistent with my memories of 128kbit MP3s from the 00s |
| 17:00 |
| 17:00:31 | tm512 | I wasn't using my headphones for that quick listening test, but the only codecs that performed terribly at 128kbit were MP2 and WMA (through ffmpeg's encoders) |
| 17:00:32 | speachy | early mp3 encoders definitely lacked versus more modern ones. IIRC LAME started as a series of patches against the reference encoder. |
| 17:01:45 | tm512 | even MP2 wasn't that offensive, but both versions of WMA that ffmpeg can encode had those characteristic artifacts that I always thought sounded like the music was playing underwater |
| 17:01:58 | speachy | having more CPU cycles to throw at the compression helps a lot. keep in mind that all of these are *decoder* specifications; different encoders can take different approaches to achieve the same output waveform |
| 17:04:09 | tm512 | my experience with 128kbit music in the past probably involved quite a bit of generation loss, like ripping a CD that a friend burned that was already sourced from MP3s just downloaded online, which might've already been reencoded from a lossy source |
| 17:04:31 | speachy | yeah that's gonna be suboptimal no matter what |
| 17:18:27 | *** | Saving seen data "./dancer.seen" |
| 17:23:33 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 17:40:28 | | Quit ac_laptop (Ping timeout: 276 seconds) |
| 17:52:22 | | Quit jacobk (Ping timeout: 268 seconds) |
| 17:54:06 | | Quit lebellium (Quit: Leaving) |
| 17:56:14 | tm512 | though picking up a Sansa is probably my best option it is tempting to get one of these iRiver devices to have more 68k stuff in my collection |
| 17:56:36 | tm512 | seems all of the supported iRiver players use a coldfire SoC? |
| 17:56:44 | speachy | the m68k stuff is probably the most underpowered of any current device. |
| 17:57:04 | speachy | I think the H10 family uses the same SoC as the older ipods. |
| 17:57:43 | speachy | I do miss my old H120 though. A very solid unit. |
| 17:58:53 | tm512 | going for 68k wouldn't really be a practical consideration, I'm just partial to the architecture, lol |
| 18:00 |
| 18:00:50 | tm512 | I've got three 68000 machines right here along with a 68040 that basically self-destructed (capacitors, of course) |
| 18:09:35 | | Quit termac (Ping timeout: 264 seconds) |
| 18:20:13 | tm512 | can the Sansa e200R be either v1 or v2, or is it only ever one of those? not sure if it's still the case but the wiki suggests that the v2 has worse battery life than the v1 https://www.rockbox.org/wiki/SansaAMS.html |
| 18:20:49 | tm512 | well specifically following the link to https://www.rockbox.org/wiki/SansaRuntime.html |
| 18:49:24 | | Join jacobk [0] (~quassel@129.110.242.224) |
| 18:52:14 | tm512 | so it seems like the Rhapsody models have the v1 (ARM7TDMI) SoC? https://forums.sandisk.com/t/how-can-i-tell-if-i-my-e200-is-version-1-2-or-rhapsody/26147 |
| 19:00 |
| 19:18:31 | *** | Saving seen data "./dancer.seen" |
| 19:38:23 | | Join ac_laptop [0] (~ac_laptop@2001:910:107e:1:e29d:31ff:fe2d:a258) |
| 19:51:40 | | Quit ac_laptop (Quit: WeeChat 3.8) |
| 21:00 |
| 21:02:51 | | Quit davisr (Remote host closed the connection) |
| 21:18:32 | *** | Saving seen data "./dancer.seen" |
| 21:22:31 | aaabbb | speachy: i think the quality of the codec matters when you're trying to get the lowest bitrate that is transparent with your equipment and ears. the dac might have a crappy noise floor but if the highs from 128kbps mp3 are cut off, but 64kbps opus sounds transparent, then that's a clear win for opus |
| 21:27:18 | aaabbb | tm512: opus 160 or 192 is way overkill |
| 21:29:16 | aaabbb | 96kbps is almost always transparent for most people, except classical music where sometimes you need 128kbps |
| 21:29:52 | aaabbb | and unless you have very good equipment or get bothered by occasional dips into intensity stereo, 64kbps is also fine |
| 21:35:19 | tm512 | aaabbb: well, I'll do my own listening tests. I'd want the minimum that's reliably transparent to my ears, plus maybe 32kbps as headroom |
| 21:36:02 | aaabbb | i think you'll be very impressed with it :) |
| 21:36:25 | aaabbb | higher bitrate will reduce battery life slightly tho |
| 21:37:22 | tm512 | with a Sansa player, having the option to use a microSDHC card, storage isn't a big issue. a 32GB card is like $5 and is big enough to not necessitate going down to 96kbit or lower |
| 21:39:24 | tm512 | at least with my desktop speakers, 64kbit opus does perform admirably. haven't checked with my headphone setup though |
| 21:39:45 | tm512 | I feel like I can tell there's a difference but this isn't a blind test, so *shrug* |
| 21:40:08 | tm512 | at worst, it's pretty slight |
| 21:40:10 | aaabbb | you'll probably notice 64k not being transparent with good headphones |
| 21:40:29 | aaabbb | but 96k will certainly be transparent for most samples |
| 21:41:28 | tm512 | track I just did this non-blind test with is "Crown Shy" by Plaid |
| 21:41:46 | tm512 | gonna have to set up this: https://phintsan.kapsi.fi/abx.html |
| 21:42:16 | tm512 | unless there's better FOSS ABX software, this is just what I found with a quick search |
| 21:42:31 | aaabbb | hydrogenaudio lists some foss abx software |
| 21:42:36 | aaabbb | also you can make your own with a bash script |
| 22:00 |
| 22:29:07 | tm512 | still not a blind test, but yeah honestly 96kbit sounds great to me. friend was able to distinguish it from lossless though, apparently |
| 22:29:39 | aaabbb | a bash script could be a blind test if it chooses the samples at random |
| 22:30:12 | tm512 | ended up linking her to a set of 3 flac files, with the original, 64kbit opus, and 96kbit opus. apparently I forgot to strip the album art metadata from the original though |
| 22:30:41 | tm512 | she said she thought it was a red herring so I dunno if it actually spoiled the results |
| 22:31:00 | aaabbb | it's useless if it's not blind. you can distinguish 96kbit from lossless in a few rare situations like with symbols, certain kinds of classical music or something with a lot of detail in the side channel |
| 22:36:19 | | Quit massiveH (Quit: Leaving) |
| 22:36:25 | tm512 | I'd probably end up targeting 128kbit, then, assuming a proper ABX test proves I can't tell the difference on multiple different tracks from different genres |
| 22:37:04 | tm512 | seems promising though, really good codec |
| 22:47:59 | | Quit othello7 (Ping timeout: 264 seconds) |
| 23:00 |
| 23:01:35 | | Quit jacobk (Ping timeout: 260 seconds) |
| 23:12:26 | | Join jacobk [0] (~quassel@129.110.242.224) |
| 23:18:36 | *** | Saving seen data "./dancer.seen" |
| 23:37:17 | | Quit m01 (Quit: Konversation terminated.) |
| 23:38:52 | | Quit sch (Ping timeout: 246 seconds) |
| 23:40:08 | | Join m01 [0] (~quassel@vps-b172b88b.vps.ovh.net) |
icon identifies that the person is a core developer (has commit access).