http://x264.nl/developers/Dark_Shikari/compare.7z ABX these. Hm. There's a certain distinct way the main and the backing melodies tend to influence each other in ZUN songs. Rate them in order of quality, best to worst. * _s|mon is now known as s|mon rofl this is so weird. I know this is your magical overtone transform, because I listen to 1 and it sounds fine, I listen to 2 and it sounds better, it has a distinctly wider spectrum, but always whenever I listen to the original and a lowpassed second, after listening to the original the lowpassed version sounds "flat" - but 1 does not. Yet 2 still sounds better than 1. Final rating btw is 4 2 1 5 3. no it isn't it's 5 different encoders. =p no transform fuckery going on here ok, so 4 + original Hm. I'll guess that 1 is the original. want to change your ranking now that you know I'm not filter screwing you? Actually, given it's an ABX I should tell you what the X is. Original is 2. Not greatly. 3 still sounds objectionable. 2 still sounds marginally better than 1. Dark_Shikari: lemme guess, CELT? saintdev: at least one might be CELT. :) so, now redo the test knowing 2 is original. 4 sounds better than 2 consistently to me even knowing 2 is the original what the shit. Other than that 3 is *still* dead-last, and 1 and 5 order after 2 in no particular order. They're different and have different artifacting, but I can't rate either as being worse than the other. 4 sounds noisier to me than 2 like... a celt encode So anyways, try to match them now. CELT, CELT + branch with advanced prediction magic, aotuv, nero aac. evening folks Dark_Shikari: 3 and 5 are aoTuV/Nero and 1 and 4 are the CELT versions? I'd probably put 5 as aoTuV and 3 as nero, and I have no clue how the two CELT variants differ aurally or even mathematically so I can't tell obviously. 3 is aotuv 5 is nero 1 is the old celt, 4 is celt + magic what the blazes is aotuv? Vorbis with a non-shitty psychoacoustic model. ah. Aoyumi Tuned Vorbis sounded like a brand of dildo bofh__: funny that it's the worst Dark_Shikari: Vorbis sucks below 80kbit imho well vorbis isn't the best at low bitrates, even with aoyumi's modifications funny that celt beats it though Speaking of which, what are the Nero and Vorbis bitrates/q settings here? all 32 I chose qs to get me 32 on each one 32kbps mono yeah, Vorbis at low bitrate tends to mash low transients like drum work Did Nero encode LC or HE? I still can't decide if I hear characteristic SBR-type high notes in 5 or not, I'm probably imagining them. How do I tell? I dunno. bofh__: probably did. one annoying part about this short clip is that mono-izing it really kills its quality run mediainfo on the mp4 it spat out? oh if you didn't force LC at 32kbit it will use HE. nero uses sbr for anything below ~64kbps saintdev: it's mono though yeah wb Jarrett Dark_Shikari: what's it fr--oh god is this the final stage theme from Fairy Wars? lol Dark_Shikari: what q did you use for nero? checkers: something low it uses HE for <0.31 and HEv2 for under 0.25(??) bofh__: I picked this clip because vorbis mangled it hilariously awfully I'm only confident about the first number there Like, it's staggering how badly it fucked up the background noise. checkers: lower Hey, there's a reason I consistently rated it dead-last :P Also, I think I know why I prefer 4 over 1. Er. Over 2. apparently CELT quite often beats vorbis at low bitrates. Which is funny because CELT was designed to suck at low rates oh hey I finished Umineko ep 2 last night... Rosa's "dinner" is a lot scarier in the VN than in the anime CELT is CELP for higher bitrates right? no SILK is CELP CELT is completely novel well, I mean, CELT is MDCT-based So while 4 *is* noisier than 2, 2 has this really annoying high-pitched transient in the noise, somewhere around 14kHz, that gets clobbered in all the other versions. 4 just happens to artifact everything else the least. that's about the only non-novel thing about it. silk? I thought that was the proprietary skype one? checkers: not anymore proprietary bofh__: interesting... the original doesn't seem to have the 14khz?! oh god ffmpeg must have created it when downsampling It's faint and very high-pitched. how fucking bad do you have to be? Doesn't ffmpeg's resampler use like, a good resampling algorithm? dunno. well, resampler maybe downsampling channels, I don't know cool. I wonder how silk compares to celt for high bitrate voice recording (32kbit) oh, how did you downsample channels? just pick the left? -ac 1 checkers: Opus beats them both aka celt/silk hybrid oh. no clue if that just picks one or tries to merge. isn't 32kbit typically overkill for just voice? bofh__: merge if it tries to merge then yeah that explains the obnoxious high-pitched artifact bofh__: why would that happen? I mean, you'd have to merge pretty shittily, right? yes What does it do to merge channels? Sum both with clipping? that's cool, so the existing opus encoder is better than both?? checkers: it's just a hybrid of both encoders mega hack But yes. I sort of want to look into CELT now. bofh__: here's the really interesting part about how CELT works I'm impressed it beat both Vorbis and Nero. well, a few interesting parts * checkers listens too 1) the overlap is fixed at 120 samples (WTF?!) it was designed around 256 sample frame sizes, roughly, but it can extend to up to ~960 or so But the overlap is fixed! What's with that? Oh, it avoids pre-echo and reduces latency. Yep. 2) It can subdivide each frame into smaller transforms; useful for dealing with transients + large frame size. now comes the interesting parts 3) It codes energy and shape separately and predicts them separately! * wewk_ is now known as wewk Both are predicted in two ways a) from past frames (in some fashion) wasn't CELT or something like it used in the oldschool IP telephony apps like CU-SeeMe? Wait, it does prediction? no to Sean_McG b) from previously-coded bands in the same frame hm. e.g. it infers higher frequencies from lower ones No. You're probably thinking of a CELP/ACELP-based codec, Sean_McG. Not entirely, like SBR But as a prediction. bofh__: ahhh, yeah. CELT is used in mumble and that's where I use it energy can easily be predicted from past frames CEL*P* and CEL*T* are very, very, very different things. :V I mean, you couldjust guess you have the same energy as the previous frame that's a pretty good guess! It does this for each band. It also can trade off frequency vs time resolution, separately, in each band. That's actually a really clever trick, the separate coding of both energy and shape. It's primarily useful for two reasons 1) it retains energy (naturally) Like, it's sort of obvious and at the same time not. 2) prediction is improved because energy is better correlated with just energy i.e. you can actually *do* prediction :V as opposed to trying to correlate both at the same time The same probably works in video. Now, more interesting things are going on. http://people.xiph.org/~jm/ietfcodec/ <-- is this the current 'homepage' of opus? 4) As originally designed, it's hard CBR. It can be adapted to not do this, but that's what it was built around. Video has a lot more redundancy in time than audio does, which is why prediction already works quite well for it unlike audio. The bit allocation basically works under an assumption of CBR. And not just CBR overall, but constant bits per band. (roughly) In fact, signalling usually costs more than it's worth. Oh so it's a subband codec in the end? Well, every codec has bands it has to define allocation to some precision Okay, I see what you mean now. Anyway, go on. It has an interesting quantizer. CELT is pretty cool :) Which builds in the concept of energy maintenance e.g. to dequant in, say, h264 you input coefficients and a multiplication factor and you get back dequanted coeffs in celt, you input coefficients and the ENERGY OF THE BAND. It dequants such that the energy matches. It also has this weird thing going on with this "PVQ/CWRS" thing with a 50-dimensional entropy coder or something. Man, half of this is stuff that should have been implemented in other codecs 5 years ago, and the other half is just flat-out amazing and I have to wonder how the devs came up with it b/c it's utterly brilliant. I don't really get that. It's probably explained in a slide somewhere. Oh yeah, and there's some arithmetic coding. The energy is arithmetic coded non-adaptive. isn't most of it from ideas tried out in SILK first? no SILK is very different or was that the vorbis-replacement Oh, and to do the prediction, it FDCTs past frames. Ghost? The interesting thing about the prediction is as follows suppose you wanted to hybridize CELT with SILK that is, have SILK do LFs, what it's best at and CELT do HFs, what it's best at you can decode the SILK part and then have CELT predict from that! as if the LF was actually coded by CELT. Also, they used to have a pitch predictor, aka "audio motion vectors" they tossed it, but apparently it's coming back or something, I'm not sure. I think that was related to sample 4. holy shit, prediction, actually useful in audio. Amazing. Now, the really interesting thing Dark_Shikari: so was it ghost that tried most of this stuff in first? from all the above tell me what you think CELT will suck at most. I pondered the concept of pitch prediction once but deemed it too computationally costly for too little gain. saintdev: dunno, I don't know shit about ghost. bofh__: iirc, their original implementation was exactly that Dark_Shikari: music? I don't know its status, feel free to ask them Sean_McG: no, it does great on music. No, this would work great on music. This would work great on music and great at low bitrates. Or, at least, most music. it beats the living fuck out of mp3 at ~128kbps it is insanely efficient at coding HFs that's not hard. Sean_McG: it's hard with 5ms latency it's well known that MP3 is an awful codec I'm not sure if the usual suspects (snare drum, crash cymbal, ride cymbal, hi-hat) would cause it to struggle. Transients are generally hard, due to its hard CBR nature but: a) --vbr gives it one frame of buffer which is usually enough to absorb them b) it has a very very small transform size bofh__: yeah they tend to get "muddy" easily. so it doesn't "fail even at high bitrates" like mp3 does it will fail on those at low bitrates but so does everything else bofh__: also it has horrible transient detection B) is probably why it doesn't fail too much at things like castanets.wav I haven't seen anything that it isn't transparent at 128kbps with. But my ears suck. saintdev: what, mp3? of course :V The interesting thing is that which it sucks on more than you would expect. but even with it's horrible transient detection it still performs well! bofh__: no, CELT no, bofh__, celt So, the thing it fails hardest on is highly tonal content Hm. Distorted guitar and stuff with a broad harmonic content? Oh. rofl. Like, say, a chiptune mixed in with a guitar. Because highly tonal content you can't cheat with energy. Yes. It's like the audio equivalent of anime. All edges, no detail. Yet anime can be encoded very well at very low bitrates with a good psy model. Really? I've never seen an anime psy model. Not in a DCT codec at least! anime doesn't tend to have quick cuts I never said anime-specific, I said good :V x264's psy model is nigh-useless for anime. unless it's for the ADHD set. particularly the worst case, i.e. no detail and just pure lines Interesting, because x264 seems to encode anime really well even at really low bitrates. A lot of other stuff likes to choke. 1) 4x4 transform 2) intra prediction x264 has always done well on anime, since day 1 I love the stuff that throws all the bits at the edges and then turns everything else into blur-o-vision. lol well, yes, that's what x264 does well on but of course, if there is no "everything else" there's nothing you can optimize. much like a completely tonal audio file. But yeah, it's funny what it fails on. It fails on what you would _think_ is the easiest thing to encode. Hey, I've been toying around with writing an aacPlus encoder over the past couple months. Its limiting case is something that is probably the most piss-easy thing to encode: voice. bofh__: overview of CELT's attack detection Also yes, but it's not tuned for tonal content. Jul 31 18:55:14 lol CELT's attack detection is braindead simple Jul 31 19:03:23 for(i = 0; i < overlap) begin[i + 1] = max( begin[i], max( abs(in[i*channels]), abs(in[i*channels + 1])); Jul 31 19:03:48 threshold = .4f * begin[overlap]; Jul 31 19:04:01 that's _it_ Jul 31 19:04:14 compare begin[] to threshold, ofc. Jul 31 19:04:17 lol Jul 31 19:04:38 like i said, braindead simple. saintdev: ...rofl ｗｗｗｗｗｗｗｗｗ bofh__: it's obviously a placeholder for something good in the future the reason being -- they want to finalize the spec sooner rather than later so they're not focusing too much on encoder decision algos but it still does well! This thing's impressive, though. Go try it. Also, the code is impossible to read. I'm quite amazed that it did a better job than Vorbis, too. aka "jmspeex code" or derf code IOCCC candidate? oh yay Jean-Marc Valin code it has a few LEGENDARY lines of code that are completely impenetrable and literally look like IOCCC candidates him and bellard should get together and write an IOCCC entry together if(l>16)val=(val>>l-16)+((val&(1<>l-16); they'd win the contest forever, probably. bellard has nothing on this. OH MY GOD LOL return (_a*(_b>>shift)-(_c>>shift)+ (_a*(_b&mask)+one-(_c&mask)>>shift)-1)*inv&MASK32; I think my brain just exploded looking at that That return isn't outright terrible, just a bit cryptic. then you have functions that look like this: p=_u[_k+1]; s=-(_i>=p); _i-=p&s; yj=_k; p=_u[_k]; while(p>_i)p=_u[--_k]; _i-=p; yj-=_k; Also I wasn't talking about bellard's ffmpeg code, I was talking about like, tcc :P _y[j]=yj+s^s; i.e. "let me write my C like perl" OH GOD WHAT HAHAHAHAHAH Please tell me that had comments. Please. Dark_Shikari++ no. it has a function comment explaining it. ... sdfsdgafghfdhfgdfahdgagdsf But no per-line comments. Yeah, IOCCC entry. /*Returns the _i'th combination of _k elements chosen from a set of size _n with associated sign bits. (that wasn't the whole function, it's about twice as long as that) oh, and the fixed point/floating point abstraction results in some fun stuff. return ADD16(r, MULT16_16_Q15(r, MULT16_16_Q15(y, SUB16(MULT16_16_Q15(y, 12288), 16384)))); rt = ADD16(C[0], MULT16_16_Q15(n, ADD16(C[1], MULT16_16_Q15(n, ADD16(C[2], MULT16_16_Q15(n, ADD16(C[3], MULT16_16_Q15(n, (C[4]))))))))); return ADD16(1,MIN16(32766,ADD32(SUB16(L1,x2), MULT16_16_P15(x2, ADD32(L2, MULT16_16_P15(x2, ADD32(L3, MULT16_16_P15(L4, x2 )))))))); frac = ADD16(C[0], MULT16_16_Q15(n, ADD16(C[1], MULT16_16_Q15(n, ADD16(C[2], MULT16_16_Q15(n, ADD16(C[3], MULT16_16_Q15(n, C[4])))))))); * Sean_McG headdesks return MULT16_16_P15(x, ADD32(M1, MULT16_16_P15(x, ADD32(M2, MULT16_16_P15(x, ADD32(M3, MULT16_16_P15(M4, x))))))); Yeah, this reminds me of when I tried to make sense of some of speex's code This is one place where C++ is justified. Except literally a thousand times worse. bofh__: in short, join us in #celt saintdev: done and added to autojoin list :P that's pretty fantastic code the question is: is it efficient and imprenetrable, or is it like gpac *sigh* poor gpac take it easy folks, I'mma go watch some Lain