Related
We are having a Skill built for us which plays podcasts and audio snippets of videos. We currently serve all of this content through other traditional platforms like native mobile apps and a website.
One problem we have is that the volume of all this audio content is much lower than the rest of the sounds outputted from the Alexa device. We don't notice any similar discrepancies on the other aforementioned platforms, and the developers building the Skill say that there's no API which allows you to boost or manipulate the output volume (not the system volume).
Has anyone else had experiences with this sort of issue? We are reluctant to pump up the volume of our source files as it will affect all the other places they are listened to.
Short answer - yes it's tricky and you're not alone.
As detailed in this BBC report* on designing a voice application - "All of our experts have experienced problems in audio levels when mixing and mastering audio for smart speakers."
Official guidence from Amazon is:
Program loudness for Alexa should average -14 dB LUFS/LKFS
The true-peak value should not exceed -2 dBFS
It then goes so far as to say that,
Your skill may be rejected if program loudness:
Is lower than -19 dB LUFS
Is higher than -9dB LUFS
However, this mainly seems to apply to audio played either as part of a Flash Briefing or using the AudioPlayer Interface, and you may get away with deviating from this if using it as part of SSML output.
That said, in practice developers tend to bump the levels up on audio until it sounds good. Sticking strictly to the recommendations usually renders the volume way too low.
So, if you didn't want to increase the loudness of clips as it'd affect other platforms, your best options might be to create an Alexa-version of the audio - mixed slightly louder. Though, I recognize that this would be tedious.
*In the interest of transparency, I wanted to declare that I fed into this report.
I searched all around Google and YouTube and I could not find a definite answer to my question.
Should I use PlayerPrefs or XML files to save the all the data that is in Version 1 of my game? Or is their any other format of saving that you prefer?
My game does not have much data that will be saved onto it, but it is not very minimal either. The things that I will save in my game are: Options Menu (Sound FX on or off, game music on or off, and the 10 second Story Animation on or off), Scores for the distance you go in my game (around 10 scores, kinda like a billboard), and a very simple store where you can unlock two more characters after you have achieved a certain distance in the game. Their is not much right now but I am going to be releasing updates in my game and it will continue to grow and expand, so I would like the savings option that can be expanded upon the best. I tried my best to explain my unique scenario, if you need more information just let me know and I will add it. Thank you! :)
I searched all around Google and YouTube and I could not find a
definite answer to my question.
That's because both of them will accomplish the work. It doesn't really matter which one you use. They both can save your game data.
Now, In my own opinion, you should use XML for portability reasons.
When you save your game data with PlayerPrefs, you will be stuck with it on that platform. For example, PlayerPrefs is saved as .xml on Android and .plist on iOS and Mac OS, .dat on Windows App Store and as a registry key on HKCU\Software\[company name]\[product name] key on Windows. These are not interchangeable.
Assuming you want to allow players to transfer all player settings from one platform to another, that would be a problem. By using xml, your game will be able to use it on any platform you want. So a player can take their settings from their Android phone and use it on their PC or Mac without problems.
When you want to change your game engine from Unity to another such as UDK, you will have a hard time using the player's old data. I've seen a question about transferring player's data from Unity to another game engine. If this person used xml, that wouldn't be a problem at all. You will get negative feedback if your players lose their data due to game engine change. If you think that you never have to change game engine, remember that you are not the founder or the CEO of Unity Technologies SF. They make their own decisions and any other competitor can buy them anytime and shut them down. This happens all the time. Stick with xml if you really care about PlayerPrefs vs Xml.
I want to work on video streaming website. But I want to know what will be the best db for video streaming site? I need to help to know about this. Video streaming site like youtube.com, so what will be the best choice ?
Thanks for advance advice ?
The purpose of a database is to record and relate facts and answer questions. You can certainly capture information about videos in a database, like file name and location, title size, width and height, description, content tags, uploader, access permissions, and so on. A DBMS is an excellent tool for managing all the knowledge you need to make the site work and be useful.
The videos themselves are best served from a file system rather than from a database - most DBMSs are optimized for large sets of small values and don't have dedicated data types or operators for videos, let alone support for modern codecs and advanced video manipulation. In contrast, a LOT of software is available for processing videos stored as files.
I have to prepare a comparison between the following technologies to present it to my Project Manager, but I fell that I'm lost, so if any one can help I will be thankful
I want to compare between them in the following areas:
the support of online video streaming
the budget of using each one
Learning Time will be needed to learn the technology
Which one is the standard and will target a lot of users
The support if I found any problem
Bugs and security issues
connection to DB, SOA and web services
supporting of multi player
The support of online video streaming
Some of the X3D viewers support video streaming (and some even 3D streaming, for things such as augmented reality).
Which one is the standard and will target a lot of users
X3D is a standardized format, such as JPEG with multiple companies being able to manipulate such data and is even officially recommended by HTML5 specs whereas Unity ties you to a single company. Even if most X3D viewers are plugin-based like Flash, there exists also native implementations such as X3DOM to display/interact with X3D files for any browser that supports WebGL.
Connection to DB, SOA and web services
I would usually recommend using a webservice for interfacing with a DB, and yes, X3D can interact with webservices (XML, JSON). There is even a standard binary format that is fast to transfer and parse large contents faster.
Supporting of multi player
Some X3D-supporting providers offer a multiusers service, such as Bitmanagement's BS Collaborate server, but I've seen people using Darkstar/RedDwarf to make multiusers 3D environments as well.
the support of online video streaming
Unity 3D does not support video streaming, unless done through textures, which will give you a really slow frame rate.
I don't know for sure about X3D, but I would doubt it was really made for such tasks.
Silver light has good video support, it should be easy to stream with.
HTML only supports streaming video if using HTML 5, for which it gives the best user experience when user's browser supports it.
Flash is the de-facto for video streaming. It is extensively widespread. They use it for YouTube for example.
the budget of using each one
The cheapest of them all is HTML, it is free. Then you can theoretically set up something for free in flash using Flex SDK and server streaming technology such as Red5 (both open source and free). After that, I believe that all others would probably be on par cost wise, Unity3D coming in as the cheapest of the paid alternatives.
Learning Time will be needed to learn the technology
Listed in order of fastest one to learn to slowest (assuming no prior experience in any):
HTML
Flash/Silverlight
Unity3D
X3D
Which one is the standard and will target a lot of users
Flash is the most widespread. Its only competitor would be HTML 5, as new browsers tend to support it and its the only possible option on iOS. On the other hand, if 3D is what you want, then Unity3D is the standard for now, might be followed by HTML 5 in the future.
The support if I found any problem
Well, Unity3D would offer you good paid support, flash and silver light also (but only when you pay for streaming server licenses). HTML, X3D will not give you any support, but you can find a lot of information on the internet. There is also extensive information about Flash and Silverlight on the internet, but mostly Flash.
Bugs and security issues
All are pretty secure, I'm just not sure about X3D, but all others are comparable in term of security or bug issues.
connection to DB, SOA and web services
Easy to do with HTML, Flash and Silverlight. Harder with Unity3D, and hardest with X3D.
supporting of multi player
Multi-player what? If you are making a game, then clearly I would say your real options are Unity3D if the game is to be in 3D, Flash if it is to be done in 2D. Check out SmartFoxServer for easy multiplayer server.
My 2 cents:
the support of online video streaming:
Some X3D players do support it. Unity does in some ways : http://unity3d.com/unity/features/audio-and-video
the budget of using each one:
X3D and Unity3d are free. You can pay for Unity licenses for extra features and platforms like iOS and Android. If you need to write plugins for Unity, you'll need the $1500 license. There are no costs for distribution of Unity products.
Learning Time will be needed to learn the technology:
Both X3D and Unity3d have active communities and many online resources and offline books. Unfortunately for X3D, the best content creation tool (Vivaty Studio) is no longer supported officially, but X3D is supported in Maya, Max, Blender, and many other 3D programs. Unity's online docs are excellent and the answers.unity3d.com forum (and other forums) are free and fast.
Which one is the standard and will target a lot of users:
'Standard' Well, HTML is the broadest standard. X3D (if including VRML) is the oldest most widely used 3D standard. HTML you have. HTML5 is coming, 'real soon now' (I'm already turning blue). If you mean 'most readily available' the HTML is #1, Flash is #2 (as everyone has a browser, and most computers come with Flash installed already). Flash needs to be installed. Unity needs to be installed too, but it's at least as fast and easy to install as Flash, and it's gotten millions of downloads, so it's getting pretty pervasive. X3D requires a plugin (this should change sometime 'real soon now' with x3dom on HTML5), but the many X3D players are all a little different from each other.
The support if I found any problem:
All have much online community support. X3D has a spec committee but that's not really support per se, you'd have to contact the X3D plugin provider (Bitmanagement, Cortona, Octaga, Exit Reality, Fraunhoffer, etc.) Unity has great online community forums, you can pay for premium support, but I'd only do that if I needed a serious bug or feature that has no work-around.
Bugs and security issues:
X3D's bugs depend on which player you use. Unity has bugs, but the product is pretty solid (I've only crashed it once, and I use is all day, every day, for over a year). Both have a mind toward security, but neither of these are totally secure, especially since you can write scripts that are inherently not secure. So you have a hand in how secure YOUR content will be. Some X3D players support encryption. Unity products are compiled.
connection to DB, SOA and web services:
You can use something like AJAX or JSON or whatever in all these platforms, no? So if it's by web service, sure. If by direct local access, I know Unity can do that. Both Unity and Flash require cross-server xml files on the server to allow access cross-domain (in the web player for Unity anyway).
supporting of multi player:
Unity has excellent multi player networking components. X3D (spec) supports it too, but it really depends on which X3D player you go with as to how well it actually works. Worst case, you can use AJAX or JSON or whatever to roll your own.
Which you choose depends mostly on what you want to do with it. Flash is generally the best route right now, unless it's all about 3D, then I'd try Unity. But a year from now, HTML5 alternatives will begin to take over. Flash DOES support 3D, there are different ways it can be done. Vivaty had a full-featured X3D player written in Flash, so it can be done. There are several good 3rd party 3d plugins for Flash.
I totally agree with wildpeaks : )
Connection to DB, SOA and web services: easy to do with HTML, Flash and Silverlight. Harder with Unity3D, and hardest with X3D.
Reply: I think X3D is not hardest.
X3D(X3DOM) can interact with webservices (XML) as very easy in this example/tutorial
Flash supports hardware accelerated 3d, and comes out of the box with 3d support. In addition, there is the papervision library for more advanced 3d. Unity3d is also supported
as a flash library.
I would consider Flex as a real alternative to Flash. It has the same actionscript language, but uses a tag based syntax called MXML, similar to silverlight. Database remoting is extremely simple. You can access your .Net/Java/Php objects directly on the front end without having to deal with serialisation issues. All of the Flash libraries are accessible.
There is also the X3D player from instantreality.org, supporting video streaming & decoding, XMLHttp request via scripting and its free for non commercial usage.
Flash 3D isn't good 3D for any application of real-time 3D. It is 2.5D with some tricks.
X3D is easy to learn for simple things and harder as complexity goes up. It does have the advantage of being VRML with pointy brackets so the free content, examples and toolkits are easily found. I did comparison tests of the various players. BS Contact is the best for the ability to handle the most complex content with the fastest frame rate and rich color palette. Network support is still non-standard although XMLHTTP and database connections are easy to bolt on. As others have said, Instant Reality is coming on fast and supported by people with a deep understanding of the past implementations and future requirements.
The decision comes down to the project type. A simple comparison rating such as you are is misleading at best but thanks for giving it a shot. I've used VRML through all of its incarnations and now X3D for world building and now as a source for 3D models in video work in combination with Sony Vegas. For cost-benefit without the need to use very expensive modeling toolkits, it is the best of all the choices.
Speaking entirely in technology-free terms, what is the best way to make a mobile friendly site? That is, I want to make a site that will work on a regular computer but also have mobile versions of the pages. Should I rewrite each page? The pages will probably have different functionality, so should I rewrite the backend code? Should it be an effectively different site with the same database?
On my site, I detect user agent, and for known mobile browsers I serve a different stylesheet, with some larger/less necessary items left off some pages. The backend doesn't really change.
I added a mobile presentation layer to an operational site about a year ago. Based on the architecture of the site (hopefully this isn't too technology dependent for you) I added a new set of JSPs to accommodate mobile browsers (sidenote: see http://wurfl.sourceforge.net/ for a great way to build mobile pages independent of browser type). Additionally some of the back-end functionality was changed due to the limited functionality of most mobile browsers. So, in short, the integration wasn't as painful as one would expect.
Good luck!
This is a pretty broad question, but here goes:
If the site is primarily about the content, meaning it's not so much a service you use as it's a publication you read, then I'd try to avoid publishing two sites wherever possible. Concentrate on simple presentation using mature technologies that mobile browsers can handle fairly well.
If it's essentially a software application delivered via the network, then things get trickier, because you're going to want to consider the UI of the mobile device, and how it differs from the desktop.
This should go without saying, but either way, if you have many mobile users, you should keep that in mind when you author content for the site. Formats, length, voice, etc.
In addition to the WURFL / WALL capabilities system that todd mentioned, there are Java Server Faces libraries available that use alternate WML renderkits for mobile phones.
One way I have done it in the past was to make sure my data was abstracted well in the data tier and then use separate middle tier models to pull what was appropriate. In my case the application was a weather application and the display methods of the target devices were really limited so we opted to only show the user the essentials on the mobile devices while the website was full featured. That was probably 10 years ago when WAP was big. But these days with devices getting bigger screens, better bandwidth, you may want to consume and display the exact same data with a different view model.
I never really know what type of application will need to consume the data in the future. We do a lot of apps across platforms but the domain model rarely changes. So I end up using the same middle tier objects where I can and pulling that data in different clients. A good example of this is a recent project where we had a rich internet application (widget), a full website, and a web service consuming the same data. Data abstraction in the middle-tier really shines in this environment.
On a very high level of abstraction, there are two main caveats with mobile devices: (1) their screen is small, (2) their network connection is intermittent. This basically means that your need to present the content so that it looks fine even on a small (variable size) screen, and preferably make it cacheable too so that your users can browse the content while offline. Then there's also the problem of low bandwidth and high latency, but those are slightly less important nowadays.
This is a very thorough overview of how to make a site mobile, though i hope its fair to say that there will always be different requirements for anyone seeking to go mobile. If you have a Blog, then you could just as easily make it mobile friendly using Mippin Mobilizer; its free, provides branding customisation tools, and with a big audience already browsing a wide mix of mobilized content, there's opportunities to generate advertising revenue around your blog.
This is because the Mippin Mobilized blog then becomes part of a much wider community of content, people, news, blogs, listings, all connecting around content, and much more at the mobile site:
http://mippin.com (on a mobile browser.)
Take a look at the Mobilizing tool because it shows off what the site can do in a second:
www.mippin.com/mobilizer
Only if you have a blog of course...