So tempting isn't it? I did think about them at the time of buying the CTR.

The Celica is 21 in a few months

So tempting isn't it? I did think about them at the time of buying the CTR.

You're telling me the one with 246bhp is as slow as a Golf TDI?

Better than the Dodge Charger or Porsche 928?

Better than the 928 because they don't even have the thin excuse of serving an aerodynamic purpose, and better than the Charger because they have decorative logos on the "closed" position.

Sounds like it's verging on MaliCool territory

Wow, I didn't realise it was that old!

Actually 22, keep forgetting we're now in 2017.

Build date was May '95

Mine's my daily driver though, so I think I still win.

Nice! Didn't realise you'd kept the Puma for your daily driver.

Neither does he at the car park most days.

It's funny cos it's true.

I'mmmma let you finish but the car MrsDoc learnt to drive in has the best flip headlights of all time



OF ALL TIME

Perhaps the Audi has taste

Perhaps the Audi has taste and is objecting you your music?

First thing that doesn't work properly on the S4, and it's hardly a deal-breaker, but the MMI system seems to have an issue with really long MP3s. nip:

I suppose in Germany they are all too busy being productive and industrious to listen to music for more than an hour at a time, so Audi's software engineers never considered that workshy Brits might have MP3s running to 90 minutes. It's also possible the USB key itself is out of the car's spec, certainly the SD card support is capped at 32GB and 4000 files per card, there's no specific mention of similar restrictions on USB keys but back in 2010 when the car was made 128GB USB keys had only just come to market, so it's possible support for them is a bit wonky or non-existent.

Total guess and hardly my area of expertise but I'd wager this will be something to do with the handling and size of a single track/file which can be cued or reviewed (forward or r versed). Thinking about it, in order to be able to do this reasonably quickly in real time, the entire file needs to be "loaded" as it were (especially as you listen to the speeded up cue/reverse as you do it), and >90 mins is an uncommonly long play, big file. The software will be expecting a finitely long file? This limitation must come into play at some point, but in which case it's a limitation, not a bug.

Or the timestamp value only goes up to 59 minutes and 59 seconds?

Whereas it's always time for trance.

I'd be astonished if that were true. It would imply all sorts of weird things about the programmers.

Well, maybe not that astonished.

We're not going to get much further without data. Ideally we;'d need to establish some correlations, e.g.

1) played to x min y seconds: resumed fine
1) played to a min b seconds: resumed at c min d seconds

The questions are: for what maximum value of x:y does it go wrong, and what can we deduce from how a:b maps to c:d?

I can believe that you can't easily jump to arbitrary points in the file because lots of compression algorithms use information from the past to encode the current state (e.g. i-frames and b-frames in video codecs.) In other words, as you put it, the entire file has to be processed from the beginning.

Interesting. Is that why it takes a while to skip to the fun bits in ['cat videos' - Ed.]?

We're in a 24/7 news cycle, nie. No time for plots and exposition, just Megyn shouting what is about to happen on a loop, forever.

Interesting. Is that why it takes a while to skip to the fun bits in ['cat videos' - Ed.]?

More or less, yes.

In video codecs, most frames that appears on the screen is defined in terms of the frames that proceeded it (and sometimes the ones that succeed it, too.) So if you have a still shot of a talking head, most of the frames will only contain data about the mouth movements, as the rest of the frame is still. This means it's hard to just jump to an arbitrary point. Some frames reset this structure, partly to enable seeking -- you can jump to one of those fine.

If you jump to a frame that isn't one of the reset ones, the decoder might "rewind" to the last reset one then play forwards to your desired frame before resuming. This can cause slowness, especially if it's a crappy Flash applet doing the playback, as can be the case for "cat videos." Or it might just start playing the intermediate frames right away and you'll see corruption and smearing all over the screen for a second or two.

This is also why DVDs have chapter marks which you can skip to instantly -- they are basically pre-defined points the codec knows it can seek directly to and start decoding right away. But you can't navigate a DVD except via chapter jumping or ffwd/rwd, for this reason.

Disclaimer: I'm far from expert in this sort of thing, I'm glossing over a few details I know and surely a lot more I don't.

Ah, Megyn. *sigh*.

The compression is a 'track changes' thing?

In video codecs, most frames that appears on the screen is defined in terms of the frames that proceeded it (and sometimes the ones that succeed it, too.) So if you have a still shot of a talking head, most of the frames will only contain data about the mouth movements, as the rest of the frame is still.

That's why Ghost in the Shell is only 8Kb.