Well, I just did EDL. It shouldn't be an issue because an EDL is just number counts, but I am thinking that Vegas is either misreading the number or Resolve or Vegas is off a field.

I tried to examine the format of "EDL" files and found I doubt they are very likely to work between different software. I came across one quote that seems to summarize the whole thing:

There are many subtleties about EDLs which can foil a successful exchange of information and spoil your day.

from:

Guide to EDL Management Cleaning, Tracing, and EDL Compatibilities

@DMT3 None of them is wrong really. Both software are very different and thus their interpretation of the language varies..... So in that case, why not use XML as was recommended to you? It stores a whole lot more information and support multiple tracks, therefore it will be more accurate when used.

@bvideo The EDL worked fine between the software, Vegas is not quantizing the frame on cuts correctly.
@Steve_Rhoden yes, this was just a test I was trying. Since an EDL is just frame counts, I don't understand why Vegas is not quantizing the cuts correctly.

Unquantized frames are easily identified in Vegas Pro, but how does DaVinci Resolve identify unquantized media? I've not seen unquantized video events highlighted on Resolve's timeline in a similar way as they are in Vegas Pro (e.g. variable NTSC frame rate phone video in a PAL frame rate project where unquantized frame ends apply to almost every event) . Is it possible that Vegas Pro is identifying unquantized events that Resolve doesn't identify even though they really are present in Resolve?

I just tested the XML and it seems to work right. Looking at the EDL created by Resolve and Vegas interpretation, there is a discrepancy between the edits. The times are way off. But that still doesn't explain why Vegas is making the edit Unquantized. An EDL is just a command to make a cut at a specific frame. It doesn't know fields, quantize, etc. So Vegas should interpret the cut point as the beginning of a frame. Instead it appears to be a math error making it between frames. Oh well, it was just a test. Thanks for your input.

Do you think the EDL specifies frame positions/counts or time? If time, things can go wrong. Calculations, i.e. roundoffs etc., or discrepancies between the project frame rate configurations, or any imperfect time-based calculation could result in fractional frames, i.e. unquantized. The EDL I exported from Vegas looked like it was times with decimals, not whole numbers.

In true timecode, each number represents a specific frame. So 01:25:26:02 would be the frame at 1 hour, 25 minutes, 26 seconds and 2 frames. No other frame in that file is called that. But in the digital world, software will created its own pseudo timecode starting with 00:00:00:00 as the first frame (normally unless the camera can specify otherwise). But if I remember correctly Vegas uses timecode based on its own math unless actual Timecode exists on the original footage.But here again, that doesn't explain the unquantized. A frame is a frame, regardless of what you call it, so any math should round to a frame. There are no fractions in actual timecode.

Is all the testing being done in VP 21.315? Mxcompound has some issues with quantization I'm still trying to figure out.

@RogerS No, this is Vegas 20.

Thanks for clarifying.

@DMT3 Even with timecode in the EDL, if the project frame rate is not the same as the media frame rate, there could be unquantized events. Depends on how strictly the receiving app wants to preserve running time vs. frame numbers.

The Vegas EDL export does not use timecode. It uses times, e.g. 12412.4000. Suggests Vegas favors running time.