Test Disks and DWAA/DWAB

Flame Flame Questions
1

Just ran Test Disks on some new Mac hardware and got some surprising results. BMD and AJA disk tests bench the nvme storage at 5700 MB/s read and write over usb4/tb5.

Uncompressed/Raw
Read: 17233 MB/s (this is faster than TB can go and feels like either a lie or straight from RAM)
Write: 6256 MB/s

DWAA
read = 3017 MB/s
write = 708 MB/s

DWAB
read = 1452 MB/s
write = 335 MB/s

Isn’t DWAB supposed to be faster and better in Flame than DWAA? I am surprised at the results. Do we trust Test Disks for this sort of thing or should I be doing Write nodes and a stopwatch?

2

Remember, compressed formats require overhead to decompress. That’s likely what you’re seeing. Everything has a cost.

3 Likes
3

Oh, for sure. I was more surprised that DWAA was more performant than DWAB.

2 Likes
4

DWAB has 5-10% better compression because it operates over 256 blocks rather than 32.

That makes DWAB better for storage size, but not necessarily performance.

Size determines copy / archive speed after you have the files. Maybe not so much while making the files.

6 Likes
5

Excess RAM in a Mac is used as a file system cache, even without using Flame’s caching. I suspect it’s caching the test file when it writes, and giving you a boost on the read.

4 Likes
6

I think when we consider performance from storage one should be using the Flame Preferences-System-Storage to see how it performs?
Do the BMD and AJA test disk decode/decompress DWAB in an inefficient way perhaps?

Also DWAA and DWAB are different as they’re meant for use cases.

From openexr.com and I think the “faster to decode full frames than DWAA access” is what makes it more appropriate for Flame.
This was just my conclusion but that’s really all I know and considering not too long ago one could only get fully detailed info on EXR from the ILM website…

I reality one’s probably good either way and if roundtripping with Nuke maybe even best to use DWAA?

Screenshot 2025-10-09 at 8.54.24 AM
Screenshot 2025-10-09 at 8.54.24 AM2266×810 110 KB

7

The uncompressed, dwaa, and dwab results I posted were from Test Disks in the Flame Prefs! The BMD and AJA tests just do ProRes I think as they are more editor-oriented.

8

ahhh snap, very interesting!
Maybe @SamE is onto something with his suspicions.

1 Like
9 
| Feature     | DWAA Compression  | DWAB Compression     |
|-------------|-------------------|----------------------|
| Block Size  | Compresses        | Compresses           |
|             | 32 scanlines      | 256 scanlines        |
|             | at a time         | at a time            |
|-------------|-------------------|----------------------|
| Compression | Slightly lower    | Slightly higher      |
| Ratio       | (less aggressive) | (more aggressive)    |
|-------------|-------------------|----------------------|
| Memory      | Lower memory      | Higher memory        |
| Usage       | usage during      | usage during         |
|             | decompression     | decompression        |
|-------------|-------------------|----------------------|
| Latency     | Lower latency     | Higher latency       |
|             | for partial reads | due to larger blocks |
|-------------|-------------------|----------------------|
| Use Case    | Better for        | Better for           |
|             | interactive       | archival             |
|             | workflows         | or final delivery    |

Both DWAA and DWAB use JPEG-like lossy compression tailored
for high-dynamic-range (HDR) image data.

DWAB’s larger block size means it can achieve better compression
ratios at the cost of read performance and memory usage.

DWAA is often preferred in VFX pipelines where fast access to
partial image data is important (e.g., previewing or compositing),
while DWAB suits scenarios where storage efficiency is prioritized.

2 Likes