[ Help ]
Old projects, multicam, multichannel audio, nested sequences
Four edit structures that resist conversion, what actually happens in each, and what comes through intact.
The short answer
These four cases fail for two different reasons, and confusing them wastes time. An old project and a nested sequence fail because of the container: the file will not open, or the interchange format has no way to describe a timeline inside a timeline. Multicam and multichannel audio fail because of the content: the information exists in the project but no classic interchange format can carry it. The first two are solved by changing what reads the file, the last two by changing the output format.
An old Premiere Pro project refuses to open
CS3, CS4, CS5 project, "this project was saved in a newer version", unreadable .prproj from 2010
Why it happens
Premiere Pro writes a version number into the project and enforces it in both directions. A recent version refuses to open projects that are too old, and an older version refuses whatever a newer one wrote. There is no backward-compatible save that solves this in the general case.
On top of that sits a constraint that is not technical at all: without an active Creative Cloud subscription the file opens nowhere, whatever its version. That is often the real reason a 2012 project became unreachable.
The format itself changed along the way. Before CS4 the .prproj was uncompressed XML; since then it is the same XML compressed with gzip. Both remain readable by a tool that knows how to decode them, because the structure of the edit did not disappear, only the application willing to open it changed.
How to get out of it
- If you still have a subscription, the Creative Cloud application lets you install an earlier version of Premiere Pro. Open the project with the version that wrote it, then export XML.
- If the subscription is gone, there is no route through Premiere at all. You need something that reads the file without the application.
- For an old project, aim for XML (XMEML) rather than FCPXML: it is the format applications of that era understand best, and current applications still read it.
- Check the extension before anything else. A .ppj file is not a .prproj: it is the Adobe Premiere 6.5 and earlier format, one generation before, and it is not supported.
PR2XML reads .prproj files from Premiere Pro 1.5 (2004) through the current version, including the uncompressed pre-CS4 format. Nothing to install, no subscription, and no need to re-save the project first.
A multicam sequence arrives with a single angle
Multicam to DaVinci Resolve, angles no longer switchable, empty multicam clip after import
Why it happens
A multicam clip in Premiere is not a shot, it is a container: a source sequence gathering every synchronised angle, plus one decision, which angle is live at each moment. The two are different in nature, and only the second resembles something an interchange format can write down.
No interchange format carries a multicam that is still switchable. FCPXML and XMEML describe a run of clips on tracks; they have no way to say "this shot is six synchronised cameras and we are watching the third". What crosses over is the edit as seen, not the mechanism that made it.
That is also why an unflattened multicam is among the elements that most often vanish from an XML export without warning: the destination application finds nothing it recognises and skips the item.
How to get out of it
- Flatten before exporting. Duplicate the sequence, then apply Flatten to the multicam clips to lock in the chosen angle. You get an ordinary timeline, which crosses over intact.
- Keep the original multicam sequence alongside. Flattening is for the export; if you need to change an angle later, that happens in the Premiere project, not in the converted file.
- If you need a live multicam inside DaVinci Resolve, it has to be rebuilt there: import the rushes, sync them and create a Resolve multicam clip. The converted edit then serves as the conform reference.
- Check the converted timeline at the cut points between angles. That is where an original sync error becomes visible, because switching no longer hides it.
PR2XML reads the selected angle and lays it down as a normal clip. Angles are therefore flattened to the active one rather than staying switchable, which is the only thing an interchange format can describe faithfully.
Multichannel audio ends up on a single track
Polywav, field recorder, 8 microphone tracks, channels mixed up on import, DaVinci multichannel audio
Why it happens
A field recorder file, a polywav, holds several microphones in a single file: one channel per person, usually plus a mix. In Premiere, each clip stacked on the timeline plays one specific channel of that file, and this assignment is stored outside the description of the shot.
Interchange formats describe clips and tracks, not the internal routing of a file. An FCPXML or an XMEML says "this clip comes from this file" without saying which channel of that file should come out. The destination application then applies its default rule, usually the first channel or the mix, and the microphone-by-microphone layout disappears.
FCPXML adds a difficulty of its own: on import, DaVinci Resolve groups audio tracks whose clips do not overlap. A timeline carefully split into dialogue, music and effects comes back merged, even when the channels were right.
How to get out of it
- Use the native DaVinci Resolve format rather than an interchange format. It is the only one with somewhere to write which channel each clip plays.
- If you must stay on interchange, export XML (XMEML) alongside the FCPXML: XMEML preserves the multi-track layout as it was. You can then copy the audio tracks from the XMEML timeline into the FCPXML one.
- Manual last resort: in Resolve, select the clips concerned and fix the source channel in the clip attributes. It is reliable but slow, and has to be redone on every re-import.
- Check a single clip before processing the whole timeline. If the right microphone comes out of the right clip, the rest will follow; if not, it is the output format that needs changing, not the clips.
Towards the native DaVinci format, PR2XML routes polywavs microphone by microphone: each stacked clip plays its own channel, tested up to 12 channels per file. Channels also keep their original names in the media pool.
Nested sequences disappear or arrive flattened
Nested sequence Premiere to Resolve, compound clip, timeline inside a timeline, empty nested sequence
Why it happens
A nested sequence is a timeline placed inside another timeline. It is a recursive structure, and interchange formats do not handle it the same way: FCPXML can describe it, XMEML cannot at all. The same edit exported in both formats therefore gives two different results, and XMEML is the one where the sequence vanishes.
That is why nested sequences are among the elements most often missing after an XML export from Premiere: the chosen format simply had no word for them.
In DaVinci Resolve the equivalent exists and is called a compound clip. It plays the same role, but nothing translates automatically between the two if the transport format does not carry the nesting.
How to get out of it
- If the edit contains nested sequences, do not export XML (XMEML): that guarantees losing them. FCPXML and the native Resolve format are the two routes that keep them.
- If you are stuck with XMEML, flatten first: open each nested sequence, copy its contents and paste them into the main timeline. You lose the structure but not the shots.
- Watch the audio of a nested sequence. It travels inside the container; laying it on an audio track of the parent timeline as well would make it play twice.
- After import, open the compound clip in Resolve and check its contents before going further. An empty nesting is otherwise noticed much later, often at export.
Towards the native DaVinci format, PR2XML converts nested sequences into compound clips, contents included. A nested item placed on an audio track is deliberately ignored, because the compound clip already carries its own audio.
Frequently asked questions
- Can a Premiere Pro project be converted without Premiere Pro installed?
- Yes. The .prproj is a gzip-compressed XML document: it can be read without the application that wrote it. PR2XML decodes it directly, which also covers projects whose Premiere version can no longer be installed or whose subscription has expired.
- How old can a .prproj file be and still be readable?
- Back to Premiere Pro 1.5, released in 2004, including the uncompressed XML format used before CS4. Adobe Premiere 6.5 and earlier .ppj files are not supported: that is a format predating .prproj, not merely an older version of it.
- Does a multicam edit stay switchable after conversion?
- No, and no interchange format allows it. The selected angle is preserved and laid down as a normal clip. To get a switchable multicam back, it has to be rebuilt in the destination application from the synchronised rushes.
- How do I keep field recorder microphone routing?
- By exporting to the native DaVinci Resolve format. It is the only one with a field for saying which channel of a polywav file each clip plays. In FCPXML and XMEML the information has nowhere to live and the destination application falls back to its default channel.
- Should nested sequences be flattened before converting?
- Only if you export XML (XMEML), which cannot describe them. In FCPXML and towards the native Resolve format they are preserved; in Resolve they become compound clips.
- Why do my audio tracks end up merged in DaVinci Resolve?
- Because FCPXML describes audio by roles rather than numbered tracks, and Resolve groups clips that do not overlap on import. XMEML preserves the original layout, and so does the native Resolve format.
Test it on your own project
Analysis is free: drop your .prproj and you will see the rebuilt timeline, tracks and clips included, before deciding anything.