Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Why are there no .gif's with sound?

Name: Anonymous 2010-05-06 10:51

And when are we getting them?

Name: Anonymous 2010-05-06 11:17

.gif is not a video format

please get a vasectomy or tubes tied so as not to pollute the gene pool with your dangerously retarded genes

Name: Anonymous 2010-05-06 11:39

There's a jQuery plugin to sync sound to gifs.

Name: Anonymous 2010-05-06 12:08

There's also Flash

Name: Anonymous 2010-05-06 12:31

>>2
If it were, that still wouldn't make sense.

Why would a video format have sound?

Name: Anonymous 2010-05-06 12:35

where all them .wavs with pictures
im sure it is just a wrapper file type so y not wrap pictures in it ???

Name: Anonymous 2010-05-06 12:51

You should use the free MNG format instead.

Name: Anonymous 2010-05-06 13:27

Never. Just use already existing tools to hack together what you need. Use MKV containers and MP3 audio and be done with it.

Name: Anonymous 2010-05-06 13:49

>>7
In case you're really that out of it, the stupid GIF patents expired quite some time ago, PNG does animation, and MNG is supported practically nowhere
IHBT

Name: Anonymous 2010-05-06 14:30

>>8
I'd rather he use something better than MP3. There's no reason to use MP3 today and in the future, unless you want compatibility with obsolete devices which only support MP3. Suggested alternatives:
- lossy: Vorbis(2.0), AAC(2.0 and higher), AC3 (not as much).
- lossless: FLAC, wavpak, Monkey's Audio, many others.
While Vorbis compresses slightly better than AAC, it's probably less supported on portable devices/standalones, while AAC is likely much better supported.

MKV is likely the current best(when it comes to features and supported formats, it's also relatively low overhead) container at the moment. As for video, H.264/AVC1 is a good choice, unless you have a good reason not to use it (like encoding something for a commercial enterprise that can't afford paying patent royaltees - this is rarely an issue for individuals, as everyone uses it, much like MP3 and many other patented formats).

The only reason using an inferior stream encoding (audio or video) would be acceptable is when the stream is encoded in a lossy way and you would want to avoid recompressing it in another lossy way and degrading the source further.

Name: Anonymous 2010-05-06 14:34

>>9
APNG (which I'm assuming you're referring to when you say ``PNG does animation''; in reality, the ``PNG that does animation'' is MNG) is supported practically nowhere as well, and certainly isn't anything approaching a standard, unlike MNG. It's a dirty hack, the only advantage of which is that it can pretend to be a regular PNG to software that doesn't support it, and that isn't the behavior you want 99% of the time.

Name: Anonymous 2010-05-06 18:09

>>11
APNG was invented by and is supported in Firefox, it was used for the throbber but that has been replaced since (at least on trunk). As of today the only APNG image in widespread use is the Wikipedia example.

Name: Anonymous 2010-05-06 18:18

>>10
AC3
Please don't do that.

FLAC, wavpak, Monkey's Audio, many others
Please use only FLAC (or wavpak is you must). Do not use Monkey's Audio (or any others) under any circumstances.

Vorbis compresses slightly better than AAC
Not really. The best AAC encoders available today will generally outperform aoTuV at any bitrate, specially at very low ones if the High Efficiency extensions are used.

That said, and unlike Theora, Vorbis is a fine choice and the differences are not fundamental.

AVC1
Pig disgusting Windows FOURCC. It's just AVC

Name: Anonymous 2010-05-06 18:46

>>13
Please don't do that.
High bitrate AC3 is better than MP3, but if you're going high-bitrate, you might as well use FLAC, but If you're just remuxing some AC3 audio from somewhere, you might want to avoid re-encoding it.
Please use only FLAC (or wavpak is you must). Do not use Monkey's Audio (or any others) under any circumstances.
Just saying there is a large choice of decent quality lossless codecs. FLAC/wavpak are reasonably well supported and they're actually the only ones I've used on a regular basis.

Name: Anonymous 2010-05-06 22:59

Vorbis
Unfortunately ogg fucking sucks a goat dick

Name: Anonymous 2010-05-06 23:25

So are we getting .gif's with sound soon or not?

Name: Anonymous 2010-05-06 23:29

>>1-16
Back to the audioboards, please.

Name: Anonymous 2010-05-06 23:47

>>13
If it's lossless, who cares?  conversion between lossless formats is also lossless.

I use ALAC (Apple Lossless) for iPod/iPhone/iTunes compatibility.

Name: Anonymous 2010-05-07 0:13

>>18
I care because it's fucking inconvenient, specially if it's a format supported by very few apps (or generally a single library) and decodes at a speed that makes Ruby look like CPU microcode.

Name: Anonymous 2010-05-07 0:29

I use ALAC (Apple Lossless) for iPod/iPhone/iTunes compatibility.
My iPod plays FLAC just fine.

Name: Anonymous 2010-05-07 4:43

>>20
That's fine if you never leave your house. Personally, I'd rather not waste my battery on software decoding.

Name: Anonymous 2010-05-07 6:01

>>21
So iPod decodes ALAC in hardware?

Name: Anonymous 2010-05-07 8:58

>>22
Not >>21, and I'm not sure about the iPod, but a lot of devices are built on SoCs that have hardware supported decoders.

Name: Anonymous 2010-05-07 9:14

>>23
iPod has hardware for MP3 and AAC decoding, last I checked. which was shortly after it was introduced, because I stopped giving a shit very fast

Name: Anonymous 2010-05-07 9:23

>>24
Now I understand why iPod sounds so miserable.

Name: Anonymous 2010-05-07 9:24

http://code.google.com/p/android/issues/detail?id=1461#c61
Android decodes everything in software, and my phone still has enough battery to play music for a good 8-10 hours. If the iPod can't do that, it's doing something wrong.

I think hardware decoding chips are overrated.

Name: Anonymous 2010-05-07 13:34

>>26
I think hardware decoding chips are overrated.
For audio I wouldn't know. For video... well, no, not overrated at

Name: Anonymous 2010-05-07 14:26

>>25
Actually it's the DAC and the iPod earbuds and post-processing. The digital output of the hardware decoder is exactly what it should be... but then it gets pushed through a limiter, out that shitty DAC (the DAC probably itself isn't that bad) and then finally acoustically rendered by a pair oh earbuds with all the nuance of a tin can.

>>26
They're certainly not overrated. I don't know what kind of battery "Android" runs on (hint: specify a device model or shut the fuck up) but the ZuneHD has a smaller battery than whatever you're using and will play for over 3 times as long thanks to hardware decoding.

Name: Anonymous 2010-05-07 17:30

>>28
The digital output of the hardware decoder is exactly what it should be...
How do you know this?

Name: Anonymous 2010-05-07 18:09

>>29
No, but there is absolutely no reason to expect it to be inaccurate. Making it inaccurate while still functional would not save you anything--not time, not CPU, not power. It's not like the less significant bits are harder to decode.

Besides, the kind of error it could introduce is not the kind you could actually hear in a functional decoder and so my blunt assertion was meant to put an end to this nonsense thought process, not to be definitive. More importantly the limiter has very audible effects on the sound, and in fact is quite obviously responsible for the bulk of the ``signature'' iPod sound character, if you will.

Name: Anonymous 2010-05-07 20:02

>>28
They're certainly not overrated. I'm a big fat idiot, and I like to make completely ridiculous and irrelevant statements. Also I lick anus.
Fixed that dickwaving for you.

Name: Anonymous 2010-05-07 20:17

>>31
Yeah okay:

ZuneHD1:
Power     3.7 V 660 mAh
Internal rechargeable non-removable lithium-ion polymer battery
Audio - 33 hours (wireless off)
Video - 8.5 hours
CPU     Nvidia Tegra APX 2600
One ARM11 and one ARM7 general processing cores


nVidia Tegra APX 26002:
HD AVP (High Definition Audio Video Processor)
    * 720p H.264 Baseline Profile Encode or Decode
    * 720p VC-1/WMV9 Advanced Profile Decode
    * D1 MPEG-4 Simple Profile Encode or Decode
    * Supports multi-standard audio formats, including AAC, AMR, WMA, and MP3
    * JPEG Encode and Decode acceleration


This is merely a counterexample to an outlandish claim. If you call that dick-waving so be it, but it sounds more like penis-envy on your part. The Real WTF: I don't even have a Zune.
______________________________________________________________
1. http://en.wikipedia.org/wiki/Zunehd
2. http://www.nvidia.com/object/product_tegra_apx_us.html

Name: Anonymous 2010-05-07 22:04

The Real WTF:
back toThe Daily WTF, please

But never mind that. Who routinely makes use of 33 hours before charging? Is it really that hard to plug the thing in when you get home? I could see on a very long plane trip, say, between the UK and Japan, that it might be useful to have more power, but many planes nowadays even provide USB power, so even that is a moot point.

I think your post is straying from the topic, though: whether the battery is 660 or 1400 mAh isn't relevant, since the whole software/hardware decoding discussion was tangential to >>21's comment about FLAC taking up significant amounts of battery power. That is, any audio format decoded in software still provides a reasonable amount of play time. Note that Rockbox does just fine playing ogg and flac on iPods, and those formats obviously don't use the decoding hardware. In fact I don't think it uses the hardware at all, but I could be wrong. Realistically, even software decoding is clearly light enough on the battery, regardless of file format being decoded.

And if the Zune is underpowered and can't manage to play anything in software with 3rd party firmware that's one more reason not to buy one :)

Non-removable, really? What the hell were they thinking? Didn't learn from Apple there, I see.

Name: Anonymous 2010-05-07 22:30

>>33
Why do you willfully ignore the central point here, that hardware decoders are worthwhile in terms of energy-efficiency, and attack every other (i.e. irrelevant) detail in sight?

Anyway, I will answer the question of 33 hours. It has nothing to do with music, and everything to do with video and wireless. Regardless, 33 hours isn't a bad thing, is it? It's not underpowered either; it would also eat most other devices in software decoding since ARM11 was the high watermark in Android devices until recently. Somehow you construe the hardware decoder as a misfeature. Great job. You're fired.

Name: Anonymous 2010-05-08 11:48

>>34
Way to completely misunderstand both my post and the entire fucking topic that it was replying to.

I was trying to be nice about it, but you're a shithead who can't carry on a discussion without changing it to suit yourself, so fuck you.

Name: Anonymous 2010-05-08 11:57

>>34
Hardware decoders are usually fairly inflexible things(if there's a bug, you're stuck with it), unless you're talking about a FPGA, but then the per unit cost would be much higher. This means that if there's a bug, you can't fix it unlike software which is upgradable. The best solution isn't H.264 decoding chips, instead, you just write hardware decoders only for simple, easily testable parts of the decoding process which would be CPU intensive otherwise (things like (I)DCT transforms, certain filters, CABAC decoding and so on), then you write your decoder in software, but have it offload all the intensive parts to the hardware, thus you achieve both upgradability and low CPU usage. This also has the advantage of being able to use the hardware parts to decode not only one format, you could could use it to decode MPEG2/VC1 and other things beside H.264, as long as they're based on the same base concepts (of course, this can't be applied to more experimental non-DCT based codecs, such as wavelet-based ones, but currently wavelet-based codecs are inferior to DCT based ones, simply because people aren't giving them nearly as much attention/development time and the CPU requirements can put high-end desktop CPUs to shame.

Name: Anonymous 2010-05-08 12:21

>>36
Either you offload everything or you achieve shit. Having the CPU touch every macroblock kinda defeats the purpose of being efficient. If you have to issue individual CABAC bin reads and then send the coeffs back and so on, your battery is already dead.

All modern graphics cards ship will full HW h.264 decoders (that process whole slices completely in hardware). Number of bugs that would have needed fixing: 0

Seriously, it's not that hard. There's a test suite for a reason. When there are reports of some "new" feature decoding incorrectly in some decoder, it turns out that decoder didn't work properly on the test suite either.

Name: Anonymous 2010-05-08 12:42

>>35
What's your problem? This I responded to >>26 and I get this treatment as a result. If that's not what you want to discuss then perhaps you should leave out the substance of my post when you reply.

Name: Anonymous 2010-05-08 13:27

>>37
A right balance can be achieved. At least on the PC, it's popular to offload video decoding to the GPU, but the CPU is still what drives most of the process. CPU usage needed for decoding is very low, but it's still there. This really depends on what kind of device it is and how power efficient it must be.

That assumes that the test suite is perfect. I know that hardware model testing (test benches) is a whole lot more serious that software testing will ever be, simply because the stakes are much higher in the sense that the cost of failure is much higher.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List