Large difference in Build vs Build/Copy times

Report · May 02, 2019

I Build a completed project in two ways:

1. Build to external hard drive, and then copy to USB stick.

2. Build directly to USB stick.

I assumed Method 1 would be slower because of the extra copy. Not so. Here are the times for a 4.8GB project.

Method 1

• Build to external drive: 2 minutes

• Copy from external drive to USB stick: 10 minutes.

TOTAL: 12 minutes

Method 2

Build directly to USB: 25 minutes.

Why is there such a large difference? What is Encore or OSX doing for that extra 15 minutes?

Report · May 04, 2019

I get the same sort of results. I can't explain it, but suspect something in the way Encore's dated processes "copy" the temporary files to the usb drive.

During the early phases of the build, I believe Encore creates the actual files to go on the disk (e.g. muxes the video/audio etc streams into vob's etc). Whether building to harddrive or USB, these phases take about the same time. Then, not all copy operations are the same: some result in many steps that are not necessary if you have more efficient code.

In any event, it is clear the "right" way to get a copy on USB is to build to a harddrive and then copy!

Report · May 09, 2019

Thanks, Stan, for confirming the problem. For several years I've been meaning to sort this out. Finally got around to doing the tests, and now we both know not to build straight to USB when build time is important.

Thanks again.

Report · May 09, 2019

While I'm in the mood for testing, here are two more time anomalies…

Anomaly 1

I archive all my audio in lossless m4a format, import into Encore, and Build to wave format (inside the resulting Blu-ray m2ts files), with Encore transcoding during the Build. Here are some comparison times to transcode an m4a file (8.12) to wave format:

• Using Max (a nifty audio app for Mac)… 2 secs

• Encore's Transcode Now… 15 secs

• Encore's Build… 90 secs.

Anomaly 2

Two wave files were imported into Encore totalling 16.06. I wanted to see how long Encore took to join two wave files. Not transcode, just join.

• Build time in Encore ("Rebuilding audio tracks") … 65 seconds

• Joining the same audio tracks in tsMuxer (no video), by exporting to m2ts format ("Start muxing") … 4 seconds.

Encore sure is slow at audio processing.

Report · May 10, 2019

https://forums.adobe.com/people/Guy+Burns wrote
While I'm in the mood for testing, here are two more time anomalies…
Anomaly 1
I archive all my audio in lossless m4a format, import into Encore, and Build to wave format (inside the resulting Blu-ray m2ts files), with Encore transcoding during the Build. Here are some comparison times to transcode an m4a file (8.12) to wave format:
• Using Max (a nifty audio app for Mac)… 2 secs
• Encore's Transcode Now… 15 secs
• Encore's Build… 90 secs.
Anomaly 2
Two wave files were imported into Encore totalling 16.06. I wanted to see how long Encore took to join two wave files. Not transcode, just join.
• Build time in Encore ("Rebuilding audio tracks") … 65 seconds
• Joining the same audio tracks in tsMuxer (no video), by exporting to m2ts format ("Start muxing") … 4 seconds.
Encore sure is slow at audio processing.

Anomaly 1 - some thoughts you might not want to hear.

With m4a there is a lossy component as well as a lossless one, as "m4a" is not an audio codec specification, but a generalized container format, like .mov and .avi etc. Just because an audio file is in the m4a extension does not guarantee it is lossless. Yes, you are creating your own archives so know what settings you are using, but Encore will not know this and needs to parse the files before deciding what needs to be done with them. Unless HDD space is a problem I would always recommend backup archival in the form of either PCM (.wav or .aif) or FLAC in "Storage" compression profile (not "normal" or "best"). But that is just me.

Remember also that by using Encore as an editor, you are in territory that was not part of the original Sonic Solutions application either, but stuff in the Abstraction Layer that sits between you & the project layout. I always find it better to feed Encore with correctly specified elementary streams - .avi/.mov or .m2v for video, and either .wav/.aif PCM or externally created .ac3/.dts audio.

This now brings us into Anomaly 2, which really isn't much of an anomaly but more a consequence of an earlier decision to use Encore as an editor instead of as an assembly tool alone. When you are joining 2 wave files using Encore, you are doing so very much more than this under the hood and I would always do this in a proper audio editor that I have full control over the output from. You don't give any details on the video footage so I cannot know what the need was for adding a second wave file to be joined to the first, but what you are doing has ramifications throughout the compiler and the NAVpacks in DVD-Video specifications that detail the length of an asset as well as the temporary reference files created for it. If the video was already in the playlist then as long as the audio file does not exceed the length of the video file all will be well but if it does, then the audio will be truncated.

Ah - I have been operating under an incorrect assumption, so rather than edit I will just apologize and move right on, as you must be handling for Blu-ray given the creation of m2ts streams. Even more reason not to let Encore do any editing. The Blu-ray specs can best be described as "a bloody mess" I believe, and I have found that when any asset is ever changed or swapped out, it must be done from a differently named version of the asset or else things will get seriously messy. So for example, audio stream #1 (PCM Stereo, at 24-bit 48kHz) has been saved with the naming convention <Project>_<Playlist_Name>_<asset_name>.wav so what we would get when removing the <> and substituting actual names is SFBand_Concert_StereoMaster.wav, but if I had to update this file for any reason whatsoever it would become SFBand_Concert_StereoMaster_v2.wav and so on. The reason for this is that on importing any file or asset, the importer will create .ves files for the authoring application to use as virtual assets (along with .mui and .xui files) that are referred to by various hooks in the authoring tool. Changing an asset can alter many things, and leave references to older versions lying around that will clutter things up & if the name is not constantly changed for any revisions can get very confusing.

Encore cannot afford to take a guess, or make assumptions in the way an editor like tsMuxer can. It is also not an audio editor, but an authoring tool - and should be used as such. Sorry to go on, but I really do feel strongly about this.

Report · May 11, 2019

Thanks, Neil, for your detailed response. And thanks again for all the info you gave me in response to my Star Trek question and on the phone last year.

m4a vs FLAC

I didn’t realise that m4a was a container, not a codec. Thanks for that enlightening. But I’m pretty sure my m4a files are lossless. The file size, typically 30-50% of the wav file, tells me that there’s a lot of data inside. And MediaInfo tells me that the audio stream inside the m4a container is ALAC.

The reason I settled on m4a instead of WAV was to save space. I run five 2TB drives as backups, and want to keep all my projects within the 2TB. So I’m careful about file size.

The reason I chose m4a over FLAC was because my version of InDesign (CS6) can’t read FLAC, and also because my version of OSX (10.9) won’t indicate the length of FLAC files.

M4a has one drawback though – Audition can’t save in m4a format, so when editing audio I have to save as WAV and then convert. If I have metadata that I don’t want to lose, I fall back on FLAC.

Using Encore as an assembly tool

“…a consequence of an earlier decision to use Encore as an editor instead of as an assembly tool alone.”

I actually don’t use Encore as an editor, but as an assembly tool. For my purposes, Blu-ray is the best delivery method for my public AVs (slide shows mostly) because I don’t trust computers in public. My research showed that Blu-ray from a Blu-ray player was the most reliable method of showing AVs.

I did look into Q-Lab, but my goodness, the lengthy list on how to prepare your computer for a public performance, put me off. With Blu-ray, I insert the disk (or USB stick) and it works every time.

My Approach

I'm a hobbyist. I'm not looking towards a feature film on Blu-ray, I'm just digitising old slide shows. Blu-ray might be a possibility sometime in the future though.

Typically my public shows run for about 2.5 hours and have about 30-50 sections, coming from separate Premiere projects. There’ll be an introduction, several shorts, previews from upcoming shows, and then the main AV. The shorts and the main AV will themselves consist of several chapters. I assemble the lot in Encore, including a count-down timer for the 20-minute interval, build to Blu-ray, and away it goes on the night with one press of the button at 7:30 PM.

My approach is to export from Premiere, all the sections and chapters as m4v and wav. I check them separately as they are finished, by using Encore to build to a Blu-ray folder, and saving on a USB stick. My Blu-ray player, an Oppo, has the rare ability to play Blu-ray folders from USB sticks. Thus my original post about USB times.

Inside Encore, I make sure each m4v has Don’t Transcode status, so that the build runs quickly. When I am happy with each section after viewing in our home theatre, I archive as m4v, convert the wav to m4a, and I'm ready to assemble at a later date which could be years away.

Encore allows me to easily assemble numerous elements into the one timeline, and to build to Blu-ray much faster than real time. Each element has already been checked, so I know it's going to work. Last night, a 45 minute project built in less than 3 minutes (the PGC file was already in place). I experimented with Playlists, I experimented with Q-Lab, but I found that timelines in Encore are the best solution for me.

That explains why I wanted to test build times for joining two WAV files. Not because I wanted to join them, but because my Encore projects typically have 30-50 ‘joins’, and I wanted to know what was causing the delays. I couldn't understand why a 1GB m4v file was building faster than a 100MB wav file.

Another Question

That brings me to another question which maybe someone can answer to save me more testing.

Encore goes to the bother of “rebuilding audio tracks”, joining all the audio into one lengthy wave file with a name such as _PGC_Epgc_track_Ltrk_1_audio. That file is saved inside the Sources > Transcodes folder. But when the Blu-ray is built, it consists of numerous m2ts files, corresponding to each of the sections. That PGC file is there on my hard drive, but is not on the Blu-ray.

Why is that? Why does Encore join all the audio, then break it apart again?