A recent analysis of a Apple QuickTime .MOV file I conducted at work compelled me to write this post to discuss its file structure.
Released in 1991, Apple QuickTime .MOV files are structured by hierarchical atoms that store media data and metadata. A typical .MOV file may consist of the following atoms:
1. ftyp (file type)
The ftyp atom specifies the file format type. For example, ‘qt’ for QuickTime.
2. moov (movie) aka ‘the meat’
The moov atom defines the .MOV file since it carries crucial technical metadata like duration and display specifications.
It may have other types of sub-atoms, with at least one of the following three: mvhd (movie header), cmov (compressed movie) & rmra (reference movie). Several other sub-atoms like clip (clipping), trak (track), ctab (color table), and udta (user data) may exist in the moov atom.
The layout of a moov atom:
Data
Type
Size
4 bytes
Type='moov'
4 bytes
Profile atom
'prfl'
Movie Header atom (REQUIRED)
'mvhd'
Movie Clipping atom
'clip'
Track atom
'trak'
User Data atom
'udta'
Color Table atom
'ctab'
Compressed Movie atom
'cmov'
Reference Movie atom
'rmra'
3. mdat (media data)
As suggested, mdat contains the files audio & video data.
4. free/skip (padding) [optional]
5. uuid (user defined) [optional]
Interestingly, the file that landed on my desk came without its ftyp atom, which I learnt was only required after the establishment of the ISO Base Media File Format (ISO BMFF) standard. It is also likely that legacy tools and software at the time may omit the atom, relying completely on players like QuickTime player to smartly defer to the moov atom. Hence it is plausible that legacy .MOV files may come without the ftyp atom, hence failing to play in some players and file format identification checks.
Python was not found but can be installed from the Microsoft Store: ...
I kept getting the above error when calling Python in the command-line after upgrading Python, despite adding it to System Environment Variables. As it turns out, Windows secretly maintains aliases - python.exe & python3.exe - in ‘%USERPROFILE%\AppData\Local\Microsoft\WindowsApps’ that encourages Python installations through its Microsoft Store. While this may streamline the installation process for new users, this causes rage to those that want more bespoke configurations.
Thankfully, one can easily disable these aliases once they are made aware of them.
Step 1: Locate the aliases
Search ‘Manage App Execution Aliases’ in the Windows search bar.
Step 2: Toggle off ‘python.exe’ & ‘python3.exe’
A further step is to put ‘%USERPROFILE%\AppData\Local\Microsoft\WindowsApps’ lower in the pecking order in Environment Variables.
I was trying to install a Python package when I encountered the following error:
C:\Users\MATT-THINKPAD\OneDrive - nyu.edu\Documents\fido-1.6.1\fido-1.6.1>pip install setuptools
Defaulting to user installation because normal site-packages is not writeable
Collecting setuptools
Using cached setuptools-75.5.0-py3-none-any.whl.metadata (6.8 kB)
Using cached setuptools-75.5.0-py3-none-any.whl (1.2 MB)
Installing collected packages: setuptools
ERROR: Could not install packages due to an OSError: [Errno 2] No such file or directory: 'C:\\Users\\MATT-THINKPAD\\AppData\\Local\\Packages\\PythonSoftwareFoundation.Python.3.12_qbz5n2kfra8p0\\LocalCache\\local-packages\\Python312\\site-packages\\pkg_resources\\tests\\data\\my-test-package_unpacked-egg\\my_test_package-1.0-py3.7.egg\\EGG-INFO\\dependency_links.txt'
It turns out that Windows 11 does not accept file paths over 260 characters by default and users may remove the character path limit by editing the registry.
Open ‘Registry Editor’
Navigate to ‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem’
Edit the value date of ‘LongPathsEnabled’ from ‘0’ to ‘1’
Most students of the program don’t typically do internships in their final semester and not gonna lie, it was brutal balancing the internship on top of my graduate thesis. But I would be kicking myself if I finished the program without doing a CUNY TV internship. Why you may ask? The paper made me rethink the possibilities of the architecture of audiovisual archival workflows, plus it also lit a path for a career that I have been intrigued about. Definitely a recommended read for anyone interested in audiovisual archiving & preservation.
But long story short, I did it and learnt a ton. While audio preservation is not necessarily my expertise, I worked on creating & improving audio processing workflows for the Himan Brown Collection. Most of it was building on Sarah Wardrop’s (previous intern) work on creating an automated way to ‘restore’ and improve the quality of digitized transcription discs. This involved creating scripts to de-noise & de-click these audio recordings. Bash scripts were written initially, but Python proved to be more suited for this process with the libraries it offers. This is a post for another day.
The greatest takeaway was witnessing and contributing to CUNY TV’s constellation of scripts. From creating access copies to extracting technical metadata, these scripts carry out the archive’s processes from ingestion to archive. Automation is beautiful since it eliminates / reduces manual processes that numbs the mind, but achieving a state of automation comes with a high technical barrier. It can help institutions with challenges like backlog and lean staffing, but creating and maintaining these scripts requires dedicated technical staff that comes with significant cost that only well resourced institutions can afford.
Big thanks to Dave Rice, Catriona Schlosser & Aida Garrido for the incredible internship!