BUG: MKV & MP4 video Files with OGG Vorbis Audio causes loud crackling sound

This bug manifests itself almost every time I try to play some MP4 Video Files which has OGG Vorbis Audio track, The Video starts to play and it displays in the overlay info screen

Video: MP4

Audio: Vorbis

The Video keeps playing, but the audio starts to make cracking sound, and eventually, the Audio and Video Goes out of sync in couple of mins.

The problem happens even when the Audio output is set to STEREO or DIGITAL pass-thru or even OPTICAL.

Certain other MP4 Video files which has AAC encoded Audio tracks or Dolby Digital Audio track plays fine.

So in Summary something is broken in MP4 Container decoding with respect to OGG VORBIS audio in the current official FW Release 2.02.16 (10/26/10)

BTW, in comparison, the same files plays fine in my PC as well as WD TV LIVE with official FW 1.02.21

WD Product staff, If you are reading this posting please fix this bug.

Thanks

Is Vorbis audio even permitted within an MP4 container?  It’s more commonly used in OGG containers.

Not sure you can call this a bug or broken feature when it’s likely not a part of the MP4 spec.  I can’t find anything to verify that it should be supported.  Maybe someone else with greater knowledge of the MP4 spec can chime in…

PixelPower wrote:

Is Vorbis audio even permitted within an MP4 container?

That’s somewhat of a source of contention at the moment. :wink:

There’s no law saying what you can or can’t put in any container… but it’s rather pointless if the playback device can’t handle that type of stream.

But, I don’t see any Vorbis Code Point entries at the registration authority.  You can still put Ogg in as a private stream, but unless your playback is looking for it, any device should just ignore the private stream.

That the WDTV even tries to extract the stream, when it’s not in the WDTV “supported” list, is impressive enough.

But I’m not sure why the extracted stream should get garbled.  We know the chip can decode Ogg, whether it’s “supposed” to be in there or not.

I am no expert in MP4 Containers, All I know is According to this WIKI it seems to be a valid combination and is clearly supported on WD TV LIve and Live+ and I was just reporting the bug as it does not play in the WD TV Live HUB…

Thanks!

Actually, when I look on the Wikipedia page in the “Audio Formats” chart, it says that Vorbis in .mp4 is “not officially” supported.

As I said, that doesn’t mean it can’t be inserted as a private stream, but very few playback systems are written to recognize it.

I don’t think WD set out to support Vorbis in MP4, or they would have put it in as a supported format in the manuals and specs… I think it’s just fortuitous that it works on other WD devices.

And the chart is a little suspect, because any of the “No” tracks can be “not offically” inserted as a private stream, just like Vorbis can… the issue is that there isn’t widespread support for pulling them back out of an .mp4 file.

As a side note for a similar situation, even on my Gen1 WDTV HD, it doesn’t really matter what’s listed as being “officially” supported by WD, if it’s a codec that the chip understands, you can cram anything into a Matroska container and the WDTV plays it back without a hitch.

On that wiki it says against video mp4:

Vorbis(with private objectTypeIndication), 

Yep… in the “Audio Format” chart it says that AC3 and DTS are “supported” (whatever that means, since Apple seems to keep insisting they’re not) and that Vorbis is “not officially supported”.

In the “Information” chart, they specify that the Vorbis track has to be included as a private stream (because it isn’t a registered code point and doesn’t have a “valid” Object Type).

Vistawall wrote:

I am no expert in MP4 Containers, All I know is According to this WIKI it seems to be a valid combination and is clearly supported on WD TV LIve and Live+ and I was just reporting the bug as it does not play in the WD TV Live HUB…

 

Thanks! 

I totally agree that if the Live/Live+ successfully play the files, so should the Hub.

Just a little surprised that the older units could handle such a rare / odd combo.  :)

PixelPower wrote:

I totally agree that if the Live/Live+ successfully play the files, so should the Hub.

I hope it isn’t an indication of a deeper problem with the Hub’s media player core code.  It’s obviously not the same code, from the Live/Plus, or it would behave the same.  So, what else has been tinkered with, and what else has been broken?  :wink:

Not that this is a “bug” or “broken”, per se, since none of the WDs claim to be able to do it in the first place.

I may sound like a broken record :neutral_face: But I saw yesterday while browsing thru’ my collections that certain MKV files that have OGG Vorbis Audio also caused these loud cracking sound. It is driving me nuts! :angry:

How can I best explain the sound? - well, If you have ever experienced a situation wherein Line feeds can be inserted when web sites are not configured properly to serve mp3 files. So the good old browser such as Netscape can download mp3’s as text files. When you attempted to play these using WINAMP it used to sound garbled and there used to be a utility known as uncook95.exe to fix mp3 files which basically used to remove line feeds from the mp3 file.

Now that is how some of my MKV and MP4 files sounds when OGG Vorbis audio tracks are present.

Strangely, as I have posted before, these same files play perfectly on my HTPC, and WDTV LIVE/LIVE+

Annoying…:angry: but surely a OGG Vorbis audio decoding bug found in WD TV LIVE HUB

I updated the firmware that was released yesterday for the WDTV Live HUB to Release 2.02.19 (12/1/10) and the audio crackling noise still exists (of-course it was never fixed in this release according to release notes but I just wanted to let WD know)

Here is the Media information that can possibly give the developers some clue about the loud cracking noise found in MKV files and or MP4 files with OGG Vobris Sound,


Format                           : Matroska

File size                        : 60.6 MiB

Duration                         : 3mn 19s

Overall bit rate                 : 2 553 Kbps

Encoded date                     : UTC 2008-05-26 05:14:43

Writing application              : mkvmerge v2.1.0 (‘Another Place To Fall’) built on Aug 19 2007 10:46:59

Writing library                  : libebml v0.7.7 + libmatroska v0.8.1


Video

ID                               : 1

Format                           : AVC

Format/Info                      : Advanced Video Codec

Format profile                   : Main@L5.1

Format settings, CABAC           : Yes

Format settings, ReFrames        : 8 frames

Codec ID                         : V_MPEG4/ISO/AVC

Duration                         : 3mn 19s

Bit rate                         : 2 387 Kbps

Width                            : 960 pixels

Height                           : 720 pixels

Display aspect ratio             : 4:3

Frame rate                       : 23.976 fps

Color space                      : YUV

Chroma subsampling               : 4:2:0

Bit depth                        : 8 bits

Scan type                        : Progressive

Bits/(Pixel*Frame)               : 0.144

Stream size                      : 55.6 MiB (92%)

Writing library                  : x264 core 54

Encoding settings                : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x1:0x131 / me=umh / subme=7 / brdo=0 / mixed_ref=0 / me_range=32 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=12 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=3 / wpredb=0 / bime=0 / keyint=250 / keyint_min=25 / scenecut=40(pre) / rc=2pass / bitrate=2387 / ratetol=1.0 / rceq=‘blurCplx^(1-qComp)’ / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30


Audio

ID                               : 2

Format                           : Vorbis

Format settings, Floor           : 1

Codec ID                         : A_VORBIS

Duration                         : 3mn 19s

Bit rate mode                    : Constant

Bit rate                         : 160 Kbps

Channel(s)                       : 2 channels

Sampling rate                    : 44.1 KHz

Compression mode                 : Lossy

Video delay                      : -42ms

Stream size                      : 3.80 MiB (6%)

Writing library                  : libVorbis 1.1.1/1.1.2 (UTC 2005-03-04)


Thanks! for looking into this, hopefully it will get fixed in the next FW release.

I just got my WD TV Live Hub a few days ago because I got tired of reencoding all my MKV files (with mixtures of AAC, AC3, DTS, VORBIS, FLAC audio tracks) into MP4s with AAC so they could be played on my PS3.

I have been experiencing a similar problem.

MKVs with AAC, DTS etc audio seem to play fine so far but the few MKV with vorbis audio I’ve tried tend to make random “squelching” noises during playback yet play fine on my PC or when reencoded to MP4/AAC and played on the WD TV live hub.

Hopefully this becomes a recognised bug and fixed with a firmware update as having to still reencode my files defeats the purpose of buying the hub in the first place.

Cheers

Dr Ravage

I’m recoding all my MKV/Vorbis as I have the EXACT same periodic squelching noise. I tried 20 different MKV/Vorbis files and every single one had problems.

None of the programs that are supposed to recode ONLY the audio work very well. I’ll look around, but if I can’t find much I’ll use MKVMerge to create ONLY the Vorbis file, then recode it and remux the new audio file (AAC). Seems a hassle though.

“Super” doesn’t work. “Mediacoder” also **bleep**. There’s probably one that works okay.

*I’m hoping that WD can fix this issue so I’ll hold off for now. I suspect it’s fixable.

Yeah I use MKVextract to extract the vorbis file, mediacoder to convert to AAC then MKVMerge to remux. Works well but as mentioned, very tedious. Hopefully the will be acknowledged as a bug and fixed soon. Cheers

As of  FW Release 2.03.24 (12/30/10) This bug still exists!!! 

WD can you please acknowledge this problem and Please fix this.

WDTV Live Plus 1.04.10_B

I’m experiencing this problem as well, with a MKV file that has a Vorbis 2.0 @ 96 Kbps stream. Popping and cracking sounds throughout playback about every 10 seconds. It doesn’t seem to get out of sync though.

The audio stream plays fine when viewing through VLC, and I’ve extracted the Vorbis track by itself and it plays fine as well, so this is an issue with the WDTV Vorbis playback.

I have not upgraded to latest firmware because of reported problems with wireless adapters.

Can WD please comment on this issue?

-Chris

More details on Vorbis stream that chokes up WDTV Live Plus:

Audio #2
ID : 4
Format : Vorbis
Format settings, Floor : 1
Codec ID : A_VORBIS
Duration : 2h 34mn
Bit rate : 96.0 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 106 MiB (1%)
Title : English Commentary Vorbis 2.0 @ 96 Kbps
Writing library : libVorbis 1.1.1/1.1.2 (UTC 2005-03-04)
Language : English

Got the exact same problem. 

VORBIS makes this annoying sound.

Weird thing is that with previous fw versions, i hadnt experienced anything similar. Noticed that at 1.04.10 (which was and the first fw update i made)

Hope it get fixed soon. 

My animelist is waiting!

Thx

Greg

I am haveing the same exact issue with my live plus only thing is that it also has the same problem in .ogm containers which are clearly stated to be supported on the box of the live plus.  Well i cant think of ever seeing a ogm file that dosn’t use ogg audo stream so it seems pretty clear to me that ogm is not supported and thus this could be interpeted as false advertising and should be fixed in the next updated or two for fear of a lawsuit.

KrackDaddyKane wrote:

I am haveing the same exact issue with my live plus only thing is that it also has the same problem in .ogm containers which are clearly stated to be supported on the box of the live plus.  Well i cant think of ever seeing a ogm file that dosn’t use ogg audo stream so it seems pretty clear to me that ogm is not supported and thus this could be interpeted as false advertising and should be fixed in the next updated or two for fear of a lawsuit.

Can you point me to somewhere where it says that the unit supports ogm.