Recomendados
Más contenido relacionado
Similar a GDC09 Loc Summit Fable2
Similar a GDC09 Loc Summit Fable2 (20)
Más de SIG-Glocalization
Más de SIG-Glocalization (15)
GDC09 Loc Summit Fable2
- 2. Jason Shirley Audio Producer Microsoft Games Studios - Ireland ローカライズのケーススタディ
- 5. Jason Shirley Audio Producer Microsoft Games Studios - Ireland Jason Shirley オーディオプロデューサー マイクロソフトゲームスタジオ
- 19. Jason Shirley Audio Producer Microsoft Games Studios - Ireland Will Braham デザインプロデューサー ライオンヘッドスタジオ
- 24. テキストパイプラインの概要 ライオンヘッドのテキストデータべース 英語版 book.xml 英語版 Char1.xml Char2.xml Char3.xml 分割ツール ローカライズスタジオを用いたローカライズ 翻訳版 Char1.xml Char2.xml Char3.xml 分割ツール 翻訳版 book.xml 英語版テキストとビルド 翻訳版テキストとのビルド アセットのビルド アセットのビルド
- 27. Jason Shirley Audio Producer Microsoft Games Studios - Ireland Palma Cedele プロダクションコーディネーター Binari Sonori （イタリア）
- 40. Q&A
Notas del editor
- Good afternoon ladies and gentleman, I’m Fabio Minazzi, I have been invited by the Advisory Board of this Localization Summit to introduce this last session of the day. Today we’ve covered several general localization topics: challenges of opening new markets, the usage of tools, globalization issues, and so on. Well, now we are happy to share with you the experience of real case of localization: Fable 2, a game that you all probably know well, which is not only a reference masterpeice of digital entertainment but also for many aspects a reference case study of localization To this purpose we’ve gathered 3 speakers who had key roles in this localization project, asking them to work on a joint presentation to explain how it alll happened from the point of view of the different stakeholders in the project. Jason Shirley, Audio Producer at MGS Ireland will speak on behalf of the large MGS team that worked the project on both sides of the Atlantic, Will Braham, Design Producer at Lionhead in the UK will represent the development team and describe how this was involved in localization, Palma Cedele, Production Coordinator at Binari Sonori, in Italy, will talk on behalf of the international team which was supported by local production units based in each target country We hope that overall the presentation will compose into useful scenario and provide you insight on state of the art localization, under the technical, creative and organizational points of view I’m sure that each speaker would be able to talk for days about their project, but I’ve asked them to focus on the main topics so at the end we can have 10 nice minutes for your questions. And now the word to Jason Shirley of MGS, enjoy! .
- Good afternoon! My name is Jason Shirley. I’m an audio producer from Microsoft Games Studios. Our localisation team is located in Dublin, Ireland. My Role in Fable II was split across the UK VO production and the localisation Production.
- I’m going to talk about some of the success factors that made Fable II localisation efficient and less painful? A little about the MGS Ireland team and the Fable 2 team What was involved in the Fable II localisation The successes Some of the Tools and Technologies And some conclusive recommendations
- MGS Ireland is located in Ireland’s Capital Dublin. We manage the European localisation of up to 14 European languages for Xbox and G4W. This includes first party, second party and casual games. Our team is made up of, Engineers, Testers, Project managers, Audio Producers and Management. We partner with 10 Loc Vendors covering Translation, Test and Audio. The vendors we use are based in different locations around Europe. For the purpose of translation and VO production we insist on in-country native professionals for the different languages. This means content is recorded by professional actors from and in the different countries which ensures high quality casting and acting. Some recent titles the team have been working on are Gears II, Halo3, Halo Wars, Scene-It, Mass Effect, Fable II
- Here’s the team that made up Fable2 Localisation Will Braham : Design Producer Declan MacHugh : Project Manager Virginia Spencer : Loc PM Jean-Philippe Chassagne : Lead Engineer Alan Davis : Test Lead Jason Shirley : Audio Producer Binari Sonori are one of Microsoft’s key partners for Translation & Audio production. Palma will be talking in a little bit about Binari’s world. Logrus took care of Russian translation and audio production
- The total number of languages localised was 15. 7 full; French, German, Spanish, Italian, Mexican, Russian, Japanese 5 Partial+: Polish, Czech\\Slovak, Hungarian, Korean, Traditional Chinese 3 Partial: Nordic, Brazilian, Arabic (doc’s and box) The Asian localizations were managed by Microsoft’s loc centre in Asia.
- I’ve been in localisation since 1995 and this is by far the largest title to be localised to date by MGS. 420k words had to be divided up for translation, with staggered handoffs. We had a total of 3000 hrs of translation per language. There were 48 thousand files x the 6 languages = 276k files, This came to 93GB disc space to manage and move around. 54 actors per language = 324 actors total Fable II had 50 Quests, which equated to 238 hrs of game to test including realtime and automated triggering. The fact that the hero could be Male or Female meant all UI and VO must accommodate Male and female circumstances As is the norm with most game releases all languages must release at the same time as the UK version
- So let me tell you about the successes of Fable II Localisation. Excellent Communication: LH as a developer showed complete open engagement with localisation working together as a team with a mutual understanding. This made the loc process more efficient from start to finish which ultimately saved money. Text Management: LH used a database which provided one shared location for final text content, the ability to track changes, the status of content and the list goes on. Will from LH is going to talk a little bit more about it later. The most important thing about this was the final and most up to date text including audio scripts were always in only one place, in the database. Smooth VO Production: As I worked on the UK VO production I managed a staggered workflow with the team. This meant partial handoffs, we could lock down characters and extract scripts for them. These were then shared across multiple translators and multiple studio recordings. With this process in place it made it possible to complete the localisation efficiently and on time for our sim ship release. Build Portability : LH provided complete build portability which enabled the loc team to create loc builds independently in their own time. This took away the need to rely on the core dev team so they could focus on the English product. Also it enabled loc fixes to be made efficiently. Creation of custom tools / technology: Engineering, development, product and localisation knowledge pooled together enabled us to create custom tools to build on efficiencies, reduce cost and release on time. This team effort proved very successful on numerous fronts.
- Some of the highlights of the creation of custom tools and technologies. We had Automated testing : This is the ability to trigger all ingame audio and UI ensuring they are implemented correctly ingame. This created fantastic time savings, 2days as opposed to 7 days including thorough testing of UI and audio. Management of text content: We were given one large source file to localise with each build. (420k words) This was generated from LH’s database. Using custom tools we were able to break down its localizable content in to manageable chunks and logical groupings. The benefit was we could have multiple translators working simultaneously. Loc studio allows us track any changes to text and manage updates. Then after translation our tools recreated the localised version of the large source file for build integration. We were able to create our localised production scripts. We were completely independent of the developer enabling them to concentrate on the English.
- Language support and language interface packs: We provided LH with an API (Application programming Interface) that allowed them to implement language support. Fable 2 was able to dynamically enumerate available resources at run time. This allowed fable II to function with plug-in packs without the need for an executable change. This meant that it could: allow for dashboard language changes on-the-fly automatically support Downloadable Content (DLC) packs support the addition of extra languages after release In Fable 2, this Technology made it possible to offer an extra voice-over pack that could be downloaded for free from Xbox Live. Specifically, the original English voice over was offered for use in the non-English speaking markets. It proved very popular!
- In summary I’d like to leave with you 10 recommendations that were so important for Fable2 and also to any developer that wants to localise their product. Firstly Engage with your loc team: If you do this the rest of the recommendations fall into place easily. Let me describe a quick scene as a quick analogy. Picture a man standing with all the information he has on the product your developing made up of a jigsaw. Then picture the man throwing this delegate jigsaw over a wall. As it crashes to the ground it breaks apart scattering into pieces. The loc team frantically picks up all the pieces trying to get it back together. Localisation happens at a delicate time in a development product cycle. The development Jigsaw is not glued so needs to be transported carefully. Your loc team is their to make your product shine in other languages and other countries around the globe. Efficient communication = lower cost and higher quality. So engage with your loc team so they can help you make a great global game.
- In summary I’d like to leave with you 10 recommendations that were so important for Fable2 and also to any developer that wants to localise their product. Firstly Engage with your loc team: If you do this the rest of the recommendations fall into place easily. Let me describe a quick scene as a quick analogy. Picture a man standing with all the information he has on the product your developing made up of a jigsaw. Then picture the man throwing this delegate jigsaw over a wall. As it crashes to the ground it breaks apart scattering into pieces. The loc team frantically picks up all the pieces trying to get it back together. Localisation happens at a delicate time in a development product cycle. The development Jigsaw is not glued so needs to be transported carefully. Your loc team is their to make your product shine in other languages and other countries around the globe. Efficient communication = lower cost and higher quality. So engage with your loc team so they can help you make a great global game.
- Use a database to store text for UI and VO scripts: Preparation and management of text and audio assets is key to the success of audio production both in development and localisation. The only difference is a badly managed text in the domestic version can equal money wasted in more than just the original production but in 6 or even 14 separate productions. This can equal large additional and last minute cost at a critical time in the product life cycle. Using a database means all stakeholders can input and export content at strategic points throughout the product life cycle knowing they are always referring to the latest content.
- Build portability, Independent loc builds. This enables the loc team to fully engage with the implementation process independently and not distract the core dev team. It’s a win for localisation and development. Chronological order for scripts: For the purpose of translation it’s very helpful for translators to see as much context as possible. This is shown well by being able to see the dialogue in chronological order. So they can see who is talking to who and what their gender is and what the context is. Avoid concatenated sentences : For UI and VO breaking up sentences so you have more variation for adjectives or nouns can be very problematic for localisation. What works in English does not necessarily work for loc languages. The structure of where adjectives and nouns occur in sentences change when translated. This makes nonsense of implementation that did work for the English VO. Track VO SFX: Numerous VO effects can be produced during one game and across loads of characters and files. It’s important to document the process including what actual files require what process. This is to ensure the loc version is consistent in sound plus efficient in post production.
- SFX Batch processes or realtime DSP: SFX done using batches are always more efficient to replicate across several languages. Realtime DSP is even more efficient and ultimately reduces post production costs. For pre-rendered movies use multilingual cinematics: In the case where you have a multilingual sku use pre-rendered multilingual cinematics such as binks. These are ideal formats for saving disk space plus post production cost. The tracks can be laid out that you have shared music and sfx tracks and then a selectable VO track based on the language. This means you could have a 5.1 mix with a centre speaker VO track which swaps based on the language. Do not include pre-rendered text or subtitles in cinematics: With text in a pre-rendered cinematic localisation would involve editing the text and re-rendering the movie and having a separate movie for each language. This increases the disc requirement plus the post production cost. Avoid time constraints for non cinematic: Typically loc VO can average 20% longer than the English VO. So it is best to ensure no truncations occur by having implementation that will play to the end of VO files as opposed to being timed.
- Good evening! My name is Will Braham and was the Design Producer at Lionhead on Fable II. I was the point of contact between localisation and the development team.
- Learning from past mistakes After working on Fable 1 and The Lost Chapters there were some things we did we wanted to do better. Minimal impact on game development Our aim was to keep the team at Lionhead focused on game development rather than support for localization Process driven support rather than fire fighting To achieve this aim we set about refining our processes to reduce the need for support in the first place Collaborative Planning We worked with the MGS Dublin team at an early stage to come up with tools and processes to help solve those problems
- Text The pipeline Internal database Internally at Lionhead we use a database to track text which gives us the flexibility to check history as well as the stability of having all our text backed up. Exported as .xml The database spits out a .xml file which is then compiled into a format the game can read. Each time a new build was created by Lionhead it would be shared along with the book.xml used to make that build, this meant that the localisation teams knew that the delivered book.xml was always in sync with the build. Compiled into game format When the translated book.xml needed to be tested it could be compiled using a standalone localized asset builder we provided which would create the compiled text, audio and lip-sync data. Using the exported .xml Loc Studio Using loc studio the localisation teams could run a diff on the book.xmls to see what strings had changed from build to build and would know which new strings were added, changed or removed. Translated text stored by the localization team Most important with this whole process was that data only travels from Lionhead to the localisation teams and not the other way. All the translated .xmls are stored by the localisation teams too. This means that Lionhead didn’t have to worry about maintaining any storage for localised assets. Easy use and to manipulate Using .xml that can be opened in excel as a table made searching for strings alot easier. And the .xml format allows custom tools to be written to manipulate the text.
- The .xml Splitter Tool One of the issues with using a single .xml file to store all of our text was that in the end it contained all 50,000 lines and was about 10 megabytes in size which is too big for a single translator to deal. However the .xml format is easy to manipulate, so a splitter tool was written by the MGS Dublin team which turned the .xml into multiple smaller parts. Splitting a 50,000 line (10 MB) .xml file Each string in the .xml was given a tag (a unique ID) and a narrator attribute, it was using these attributes the book could be split into more meaningful chunks, like a quest, or a set of simulation dialogue. Those smaller chunks were sent to the translators and then when they are sent back the splitter tool was used to reverse the process and stitch the parts back together to recreate the original .xml. Male / female hero gender Another issue we ran into was the need to translate for choice of male and female hero in the game. The main problem we had here was that the strings were all written in English which is a very gender neutral language; however this is not the case for other languages. In order to provide different lines for the male and female heroes, new strings need to be created. However the English writers don’t know which lines needs to have gender variants. We couldn’t split every single line in the game into male and female variants because there would be a lot of redundant data. Instead we agreed with the localization teams on a way for them to be able to split a single English line into 2 translated lines. If the translator wanted to split a line into 2 they used a particular syntax to define which parts of the line were male and which were female. Then when the splitter tool was stitching the lines back into the original .xml it would also split these gender specific lines into 2 separate strings. Created and maintained by MGS Dublin It’s worth noting that the splitter tool was entirely developed, maintained and run from the Dublin office, other than the initial idea we didn’t have anything to do with it. And the reason this worked out so well is that it allowed Dublin to control their process without relying on support from Lionhead. All we had to do was provide the book.xml and the rest was up to them.
- Builds and Compiling localized assets Builds Builds provided daily As I mentioned before we created daily builds of Fable II, which were shared with the localisation teams. But in order for this to work there are a few extra steps that need to be taken. All builds smoke tested internally and reports sent to localization teams Sometimes builds break, and it would be a waste of time for anyone to copy a broken build, especially if they are working in a different country where the copy times can be long. We overcame this problem by having our internal test team run smoke tests on the build as soon as it completed. The results of those smoke tests were sent to the localisation team so that they knew whether or not it was worth grabbing the build. Compiling localized assets Localization Asset Build We took our main asset build and stripped out all of the unnecessary bits to create a version that could be run by the localization teams to build text, audio and lip-sync data for the game Language Interface Pack This data could then be dropped into the build and the language interface pack would recognise it as a new language which could be loaded from the front end. It was this same technology that allows the game to be localized into other languages post release without the need for the development team to add support for the new language. Localization able to create and test localized builds independently The ability for the localization teams to take a pre-made English build, drop their localized assets into it and start testing all without needing support from Lionhead was invaluable.
- Support and Communication Support Localization Asset Build At times the localization asset build process broke down because the asset builder would stop working due to certain file formats or compile processes changing. Each time this happened we had to update the standalone asset builder, there was a single programmer on the team responsible for this, and we aimed to keep the turn around as fast as possible. String Context On Fable II the text can be rather flowery, and reading the strings in an .xml file with no context could lead to mistranslation, the ideal solution would be write a line of context for each string so that the translators would know how best to translate it. However this significantly increases the content that the writers have to produce, and they don’t have time for it. We spoke with the localisation teams and agreed on a compromise, each time the context of a string was in question it would be sent to the writer at Lionhead who would answer any questions. Communication All communication channelled through MGS All communication no matter how relevant it seemed was channelled through the entire MGS Fable Localization team including the Dublin team, as well as the publishing team in Redmond and the East Asian teams. This meant that if a problem arose at 12:00 UK time and the Dublin team asked for a fix then Redmond and East Asia could read about it without having to ask the same question again. A quick turn around to all communication was essential, even when the news was bad. It’s better to tell the localization team that the build is broken and won’t be fixed for a week than to stall communication for a week and hope they don’t notice. Regular visits from the MGS Dublin team Throughout the development of Fable II members of the Dublin team made regular visits to Lionhead, these not always related to localisation for instance Jason spent a good deal of time with us sorting out our voice over production. This regular contact made working with each other a whole lot easier.
- Summary Work with localization teams to streamline processes Upfront planning to avoid fire fighting I mentioned earlier that we set out to create a process where the impact of localisation on development was minimal, and I think we achieved that. The truth is that we never would have achieved that if we had not invested the time in preparing those tools and processes. The project was a success because all parties were involved in the upfront planning.
- Palma Cedele intro
- Early kickoff For a project of this size, it is very important to get any preliminary information on volumes and type of material to be localized at a very early stage and actually for Fable 2 the localization team was involved in the planning quite soon and this helped us to set up the most suitable team. It was essential to know how much text was to be translated and how the original recording was planned in order to reserve resources in each countries and build a loc content production plan in synch with the original one. Based on the preliminary information we were able to draw a draft schedule considering a certain number of resources and based on the requested delivery dates, we were able to discuss with Microsoft the latest cut off dates on when we had to receive the material in order to meet the requested delivery dates. In order to better cope with the quantity of text to be translated and recorded, all the plan has been conceived in batches and this worked really well since all teams (developer, publisher and localization company) were all well synchronized. Our collaboration was great since we knew in which phase each team was and in case of any delay in handoffs, the same delay applied to hand-backs. It was very important the role of Microsoft in the person of Jason who worked with the development team. This was essential to inject lots of loc experience into the process. Recording was splitted into batches as well. In collaboration with Jason, we were able to split the recordings scheduling them on the characters to be recorded in order to avoid to call actors in each single batch thus reducing the costs of re-calling the same actor a second and/or a third time during the project.
- Ad hoc team building Based on all the preliminary information at our disposal a few months before the actual start of localization, we were able to build an ad hoc team for the project: International Project Management For the International Project Management we built a team of 3 Project Managers, one PM was dedicated to text translation, a second one was dedicated to the audio part of the project and a third one was dedicated to the overall supervision and planning. All of them were involved in all communications. In this way they were all aware of what was going on at all stages both on the text translation part and the audio part. International Language Coordinator We assigned an International linguistic coordinator in charge of collecting all the queries from the different local teams. As we generally do for all projects, we filtered the queries and we tried to answer them before sending them to Microsoft so that Microsoft and Lionhead got just the queries we were not able to find an answer for or for which we needed more context. In this respect, we must say that we received a great support from Microsoft and Lionhead since our queries were answered really quickly and when you work in batches, this is fundamental for reaching a high quality since quick answers avoid leaving too many pending issues in the translated files. International Audio team The International Audio team consisted of an Audio Project lead in charge of the entire process, an Audio manager in charge of resources and their coordination and 13 sound engineers in charge of all the pre and post production for all languages. All post-production was centralized in Binari Sonori in order to guarantee consistency among all languages. International Quality assurance In order to ensure audio quality, in each country we had 1 proof listener per language in charge of listening to all the files after recording in order to check the correctness of the audio files from the linguistic point of view, the interpretation point of view and the audio quality point of view. We set up a central team of different proof listeners for the final check after post production in order to guarantee a high audio quality and in order to validate the final as recorded scripts used for subtitles. In this way we could avoid discrepancies between the spoken text and the subtitle text. International Engineering team In house we also had a dedicated engineer who helped the team throughout the project carrying out standard tasks like Loc Studio formal checks, extractions of scripts in order to run internal checks for male/female gender, disassembling scripts before recording and re-assembling scripts after recording. Moreover in particular situations Project Managers and Engineer studied together the best approach on how to deal with specific files or the best way to follow in order to help translators and reviewers to have more context while working. I will show you later on some examples on how we proceeded.
- Ad hoc team building Local project teams In each country (France, Germany, Spain and Mexico) we had a team made of a Local Project Manager, a Local Linguistic Coordinator, 6 translators and 2 reviewers, a Casting manager, a Dubbing director and a local team of sound engineers. In Italy besides all the International teams we also had a team of 6 translators and 2 reviewers, a casting manager and a dubbing director as well. In Hungary, Poland and Czech Republic we had a team made of a Local Project Manager, a Local Linguistic Coordinator, 6 translators and 2 reviewers since for these languages the audio part was not involved.
- Ad hoc team building In total we had a global team of about 130 people managed both internationally and locally. From this perspective, it was a huge success that during the project we never experienced any major problem and all the local teams were able to meet required delivery dates and were all able to guarantee a good quality at each single stage so that redoes were nearly equal to zero.
- Pipelining with Development All this and the smoothness in running this project was reached thanks to the cooperation with Microsoft and Lionhead. Throughout the project, the role of the MGS Dublin was essential in managing the needs of development and localization . Specific tools have been prepared and a streamlined flow of communication with the developer was set up. The knowledge of MGS Dublin on both localization and development, acted as a hinge among all teams: development, localization and testing. Very clear specifications were set and schedule negotiated with parties for each stage of the project. Although the text was evolving during translation, the usage of Loc Studio (a tool that versions the text) and the recording plan based on batches allowed to integrate changes in each recording and basically avoid any audio pickups (actually less than 5% of contents had to be adjusted after the recording sessions). Another essential factor from our point of view was to have in-country production units able to deal with translation & audio at the same time. In a project of this size, text and audio must go coupled at all times. Redoes in text influence audio, and the changes in text imply re-recordings all the time. In each country the same production unit was in charge of translating and recording, managing from a single contact point a large team of linguists knowledgeable of Loc Studio processes and structured translation (they were all aware of specific glossaries, of the importance of consistency and QA criteria), as well as professional recording studios. This approach made it possible to keep quality consistent, have easy feed forward and feed back paths between text and audio, thus maintaining production of local contents synchronized at all levels. Another key for success was that we could rely on a great support from the developer . As I said before it is really important that translators and reviewers work having at their disposal the maximum information on context. Since it is not so easy to have final material to be used as context in a product which is still under development, we are really grateful to the development team for the quick turnaround to our questions. Questions from the language team have been processed very timely (usually between 24 and 48 hours), thus allowing to have all contents in synch at all stages of the project. This is of paramount importance in such a big project.
- Overview of Loc. Process As I said before, in order to better cope with the size of the project, scripts were divided into batches. We received 3 big chunks of text to be translated using Loc Studio. For each batch schedule was discussed and agreed together with Microsoft thus allowing us to include all our internal phases and allowing all teams to work at the right pace. Recording has been splitted accordingly but since Batch3 was really huge, we decided to split this batch into 3 sub batches so in total we had 5 recording batches. From MS we received files to be translated structured by character therefore it was not possible to understand who that specific character was talking to. In order to solve this issue we were provided with an xml file (called book) containing the overall dialogue in chronological order. The translators used this file as a reference in order to get context for the strings to be translated. With the help of this reference file, the translators were able to see who was talking to who and what the context was for each specific string. Due to the structure of the game which is a story to be played as a male or female hero, the local linguists were involved in flagging the need to duplicate lines according to the genders since English genders are mainly neutral but this is not the case for most of the other languages.
- Translation In order to duplicate the lines, the linguists had to use a particular syntax in order to define which parts of the text were male and which were female, like you can see in this example. It shows you how the linguist had to proceed when the word or the sentence needed the double gender. Translated files were then handed back to us. At this stage, files were just translated and no review had been carried out.
- Structured in context revision In order to allow the linguists to carry out a review in context, through a procedure we imported the translated text into the book.xml file. Populated book.xml file was sent to each country in order to perform review. Reviewers used the book.xml file in order to review their translations in chronological order. As you can see in this picture the yellow parts are the translated ones while there are some parts still untranslated. This parts were the ones which at that time we still hadn't received for translation but using this method, the linguists were able to review the translations considering as context also the untranslated parts. In case of any change, the reviewers had to implement the changes into the edbs and not into the xml file. Reviewed edbs were then handed back to us.
- Gender control Since it was very important that no gender was missing since this would have meant a missing recording therefore a pickup at a later stage, we decided to perform an extra check on male and female gender. Through a procedure we created an xls file in order to enable each country to view which strings were doubled by the other languages so that in case some other amendments were necessary, each country was able to fix that in the edbs. As you can see in the image in the first example circled in red, German and Italian have doubled the gender. In the second example circled in red all languages have doubled the gender. Not all the languages needed to double the gender for the same sentence since in some cases, each language evaluated if a good neutral sentence was applicable and when it was possible a neutral form was used.
- Script in Excel Format Final translated and reviewed edbs were then sent to us. We performed all the necessary formal checks on all the edbs which were then delivered to Microsoft. Microsoft through the Jigsaw tool extracted the text from the edbs sending us the scripts in Excel format to be used for our recording. In the picture you can see an example of script. The green lines are the ones which have been doubled due to the gender issue. This process was carried out for each batch. The batches of course overlapped so we had different batches at different stages but this allowed us to recycle the same resources thanks to a very detailed scheduling of each single phase.
- Audio Expert casting/dubbing direction Before the actual recording could take place, great attention was given to the casting phase. With such a huge cast, the casting activities focused on the major characters, and specialized talents were selected to render the long recording sessions without loosing the feeling and the voice. In each country we selected the most suitable voice for each of the characters based on the their descriptions and using the English voices as a reference in order to reproduce the same feeling the developer aimed to convey. The in-country studios, with a large base of professional actors were of paramount importance. For a project of this size, each country may have different requirements and each country had a certain degree of customization. For example, in some countries the use of some celebrities was requested but being on the local territory this was not an issue. Each country adopted dubbing directors with movie experience to guarantee the maximum level of quality for the locale. Post Production After recording, we performed a huge post production work. In order to guarantee consistency among all languages (therefore final audio quality), post production has been centralized in house. In the end we produced a total of about 250,000 audio files for all the 5 languages and in order to meet the delivery dates we had up to 13 sound engineers working in parallel. Full proof-listening A global quality check is essential before the final integration of the files in the game. In order to guarantee quality we had in each country a proof listener in charge of listening to all the files after the recording phase, plus in house we set up a central team of proof listeners in order to spot any audio quality issue or inconsistency after post production phase. Any issue was spotted at this stage and reported to the sound engineers for fixing before our final delivery to Microsoft.
- Recording Volumes And finally here is a quick overview on the volumes we managed in recording. In the first table volumes refer to a single language while in the second table volumes refer to all 5 languages. Volumes are divided by batches and by the different types of recording: Ingame, Time Constrains and Sound Synch.
- Audio Expert casting/dubbing direction Before the actual recording could take place, great attention was given to the casting phase. With such a huge cast, the casting activities focused on the major characters, and specialized talents were selected to render the long recording sessions without loosing the feeling and the voice. In each country we selected the most suitable voice for each of the characters based on the their descriptions and using the English voices as a reference in order to reproduce the same feeling the developer aimed to convey. The in-country studios, with a large base of professional actors were of paramount importance. For a project of this size, each country may have different requirements and each country had a certain degree of customization. For example, in some countries the use of some celebrities was requested but being on the local territory this was not an issue. Each country adopted dubbing directors with movie experience to guarantee the maximum level of quality for the locale. Post Production After recording, we performed a huge post production work. In order to guarantee consistency among all languages (therefore final audio quality), post production has been centralized in house. In the end we produced a total of about 250,000 audio files for all the 5 languages and in order to meet the delivery dates we had up to 13 sound engineers working in parallel. Full proof-listening A global quality check is essential before the final integration of the files in the game. In order to guarantee quality we had in each country a proof listener in charge of listening to all the files after the recording phase, plus in house we set up a central team of proof listeners in order to spot any audio quality issue or inconsistency after post production phase. Any issue was spotted at this stage and reported to the sound engineers for fixing before our final delivery to Microsoft.