Actually because they misused the Dolby trademark, there could be other ramifications. I love Tablo, but they may have made a serious error.
That was sarcasm lol
Tablo is headquartered in Canada - a lawsuit like that wouldnât fly here.
They didnât misuse it. DD+ can be from 1.0 to 7.1. Theyâre doing 2.0. Itâs all kosher.
I assume you are being sarcastic as well. Of course they didnât misuse the Dolby trademark. Dolby had to run tests on the Tablo to certify it, and they apparently did.
When we say âdonât transcodeâ that doesnât mean âdonât recordâ. Transcoding is the process of decoding a signal, then re-encoding it in another format. The Tablo rocks at this for video. It transcodes the bandwidth hungry MPEG2 signal into an h.264 (MPEG4 AVC) [please forgive and correct me if Iâm not 100% correct on the codecs]. This is critical in order to be able to view the video on a Roku and pretty much any mobile device.
They also transcode the audio. But unlike the stellar job they do with the video, they screw this up big time. They take a perfectly decent 5.1 signal coming from the OTA, and transcode it to 2 channel.
When we talk about âdonât transcode the audioâ, we mean âsimply record the audio into the container the same as you received it OTAâ. This is called a remux. You simply take what you got, and package it into whatever stream container format you are using. You bet youâll have sound while watching live TV as well as previously recorded. Some unfortunate folks though would not get sound on their TV speakers however. Therefore they would need to stick with the 2-channel audio transcode (as Tablo currently does) and thus be locked into 2-channel on all their TVs in the house.
While you are correct that âthe problem is purely softwareâ, its not in the layer(s) you are suggesting. This must be integrated into the logic of the firmware that is responsible for performing the transcode and muxing activity. What I am hearing from otherâs posts here is that Nuvyyo is only an apps-level dev shop and that they either do not have any embedded systems talent or they do not have access to the code/IP on that side of their product. I need to see if I can find a teardown of the Tablo to get a better idea.
Since Nuvyyo isnât really being transparent about all of this, we are making educated assumptions based on scraps of info posted in various forums.
You are also correct that this would be much better if all the players could decode and/or transcode an AC3/5.1 stream. But the reality is that, for the most part, they donât. Tablo has no control over other companies decoding engines, so thatâs really barking up the wrong tree.
So is tanscoding the audio from 5.1 AC3 to 2.0 AAC - this is critical for viewing on any mobile device.
Obviously they have a workaround if theyâre still claiming itâs on the long-term roadmap.
If that wasnât the case, why would they continue to string everyone along and not just admit that âwe screwed up, itâs impossible, sorry guysâ?
Dolby 5.1 is not impossible. We do have in-house folks that work on our hardware and the firmware that supports it.
Adding 5.1 requires a significant amount of work both from our internal team as well as support time/hours from one of our chip providers which is why it hasnât been tackled yet.
Iâd just like to reiterate the following as wellâŚ
I appreciate @TabloTv responding. Itâs a touchy issue obviously, and it affects some people more than others. I get nervous about this feature being implemented since SimpleTv never made it work, and your device is a lot more like theirs than say a Tivo. But if your developers are sure it can happen at some point, then I will trust you.
In Tablo we trust.
Horsepucky. It is no big deal to play video with only an AC3 audio track on a phone. I am literally doing it right now just to confirm. I have an MKV file that has one and only one audio track, and it is AC3. And I can hear the audio just fine. I like to use MX Player on my phone. Iâm not sure what kind of phone you have.
I do have sympathy for you, because you seem to be surrounded by devices that just will not play ball with AC3/5.1. That is unfortunate. But it is easily fixable for minor cost and effort.
I am assuming you have an Android phone?
Iâve got an iPhone 6.
I found the problem!
Now the real question is whether there are more iPhone users using the Tablo, or users wanting 5.1 audio using the Tablo?
We both know the answer to that.
Also even if natively the iPhone browser doesnât support AC3/5.1 I would bet there are codecs you can download or incorporate into Tabloâs media player.
I donât see this as a deal breaker, not one bit.
Correct. I have a Nexus 5. My household is fully Android for mobile devices.
I have very limited knowledge of iOS stuff. Are you sure that it is impossible to decode AC3 on an iOS device, even with a SW codec? I find that very hard to swallow. If indeed it is true, its entirely nonsensical.
I beat you to it
Hereâs a player that can do that, so there are obvious ways Tablo can get around this.
https://itunes.apple.com/us/app/infuse-3-elegant-video-player/id577130046?mt=8
And there are a few suggestions here for iPads.
So basically if there are other companies who have figured out how to play full 5.1 on iPhone/iPad, Tablo can do it. So thatâs not an excuse @theuser86
Plus what are we still discussing? Tablo said it could be done. Theyâre in no hurry to do it because theyâre busy creating products to grow the customer base, but they CAN get 5.1 to work in an undisclosed distant future.
@TabloTV Appreciate the response.
Adding 5.1 requires a significant amount of work both from our internal team as well as support time/hours from one of our chip providers which is why it hasnât been tackled yet.
I think this is because your dev team needs to break it up into 2 different phases. By only considering the do-it-all deliverable, the feature looks too big and may indeed have a low perceived ROI. Allow me explain:
Phase 1
Add a configurable setting to avoid transcoding the original OTA AC3 stream to 2-channel (whatever codec you guys use). The default of course must be to transcode, as the Tablo currently does. Include a sternly worded message if you feel the need â âThis setting may cause audio to be inoperable on mobile devices and many TV sets without a separate audio/video receiver. Are you sure?â
-
When this setting is enabled, itâs actually less processing on the Tablo during OTA capture since you would simply be remuxing the AC3 stream and not transcoding it. Perhaps this is already happening for you in hardware already so there isnât an appreciable performance difference.
-
This phase should be easy and relatively painless. And you have to do it anyway to get to the do-it-all solution (Phase 2).
-
The ROI of Phase 1 should be very significant. Pardon my BS bingo, but this is low-hanging fruit. The moment you release FW with this setting the pent-up demand from AVS forum and such will flock to your product. You will have a low priced, non-contract, whole-home DVR that works with 5.1. Take this uptick in sales and use it to fund Phase 2, if you want.
Phase 2
-
Eliminate the audio transcode during record setting from Phase 1. You now only capture the original AC3 stream. Or transcode to whatever format technically suits you better. So long as you retain all of the original channel information (lossy compression OK). What I mean is that if itâs better for you to transcode to some other multichannel lossy format, go for it. Just donât decimate the 5.1 tracks to 2 channel.
-
Now the hard part. And I suspect this is what your engineering department is facing as the big challenge in all of this. You must transcode in the back-end during playback depending upon the needs of the requesting client. Basically you do what Plex does. At present, the Tablo does not do anything like this on playback. It would be a substantial change. In fact, there would likely be limitations on the number of playback streams that could be handled in this manner.
-
The ROI of this phase is much lower. So you can make the wise business call to keep kicking the can down the road.
Some clarifications for some of the lesser-technical folks on the forum:
-
When I say ârecordâ that applies to both live TV and recordings that you watch later. The DVR is always recording, even if you are not. Recording means âgetting the OTA signal and processing itâ. At what point you actually send it to an STB (eg Roku) is irrelevant.
-
When I say âplaybackâ I mean the act of sending a stream from the Tablo backend box to a front-end STB (Roku, etc). Again, whether this is live TV, an earlier recording, or timeshifting/pause/unpause/whatever is irrelevant.
[If anyone with more expertise can enlighten me with more suitable jargon, that would be great].