Images and audio
Media documents, formats, limits, rights, provenance, signatures, reading and deletion.
On this page
Photos and recordings in Tidenda are documents in their own right, with their own rights record, provenance and signature. An editor uploads a file once and uses it in any number of articles; a reviewer can trace who made it, what may be done with it, and whether its bytes are the ones the platform received.
What a media document is
Each uploaded file becomes one document: core/image for a photo,
core/audio for a recording, core/video for a video clip. The
document holds the editorial
information, such as caption, alt text, rights and provenance. The
file itself is kept in the organisation's own storage and never
crosses to another organisation.
A file is never changed after upload. An edited photo or recording is uploaded as a new document, with its own id, signature and rights record. Uploading the same bytes twice within an organisation returns the existing document instead of a copy, and the duplicate does not count towards storage.
Images are kept as the original plus three derived versions:
| Version | Size | Format | Used for |
|---|---|---|---|
original |
as uploaded | as uploaded | The bytes the signature covers. |
thumb |
256 pixels wide | WebP | Lists and pickers. |
preview |
1024 pixels wide | WebP | The editor and previews. |
delivery |
full size | JPEG | Publishing. |
Audio is kept as the original plus a waveform for display. After
upload, a recording is transcribed and its speakers are told apart.
Its processing status moves from pending through transcribing
and diarising (speaker attribution) to ready, or to failed with
an error message, in which case an editor can retry. The transcript
is a list of time-coded segments; editors name the speakers and
correct the text.
When speakers introduce themselves or each other, for example "my name is", "me llamo" or "med mig har jag", the platform suggests their names. A suggestion is filled in only when the introduction is explicit, and never replaces a name an editor has set. Introductions are recognised in English, Spanish and Swedish.
Transcription, speaker separation and speaker naming all run inside Tidenda. No audio and no transcript text is sent to an external AI provider by this processing, whatever AI connectors the organisation has set up.
Video clips from a phone are uploaded in parts, so an upload over a poor connection resends only what was lost and picks up where it stopped. After upload, a clip is converted:
- a standard copy (the
standardvariant), which is what videos are made from: H.264 at a constant 30 frames a second, upright (the phone's rotation applied), in standard dynamic range (HDR footage, such as an iPhone's HLG or Dolby Vision, is tone-mapped), at most 1080 by 1920 pixels, without the original's metadata; - a preview copy, 720 pixels on its short side, which every browser plays;
- a poster frame.
Its processing status moves from pending through transcoding, with
processingPhase and processingProgress saying how far it is, to
ready, or to failed with the reason in processingError. Once
ready, the clip carries its width, height, length and whether it has
sound. A clip's sound becomes a recording of its own (core/audio)
that is transcribed like any other, with word timings; the clip links
to it with rel=transcript, and the recording back with rel=source.
When the transcript is ready, it is also copied onto the clip's
content.transcript. The original is kept exactly as uploaded and is
what the clip's signature covers.
The full field lists are in the document reference.
Formats and size limits
| Images | Audio | Video clips | |
|---|---|---|---|
| Accepted | JPEG, PNG, WebP, AVIF, GIF, HEIC, HEIF | MP3, WAV, M4A (AAC), WebM, Ogg, FLAC | MP4, MOV (QuickTime), M4V, 3GP, WebM |
| Refused | TIFF and camera RAW formats | Anything else | Anything else |
| Largest file | 75 MB | 500 MB | 512 MB |
| Longest | 3 minutes | ||
| Largest picture | 4096 x 2304 pixels | ||
| Files per upload | 50 | 10 | 5 |
SVG is accepted only for a public site's logo and favicon, up to 512 KB, and is cleaned of scripts and external references. HEIC uploads from phones work without conversion. Convert TIFF and RAW files to JPEG or PNG before upload. Audio files are stored exactly as uploaded, without re-encoding.
The per-file limits are the same for every organisation, and an organisation cannot raise them.
Storage allowance
Images, audio and video clips share one storage allowance per organisation:
allowance = seats x 100 GB + extra storage
A seat is an active member of the organisation: anyone who signs in to write, edit, plan or review. API keys and webhooks are not seats. Every organisation counts at least one seat, so the first seat always brings 100 GB. Extra storage is added on request and appears in the organisation's storage settings.
Usage is the size of every uploaded original, images, audio and clips together. Derived versions and waveforms are not counted, except a clip's standard and preview copies, which are videos of their own size. A duplicate upload adds nothing. Deleting a file releases its storage.
Owners and admins see usage, the allowance and the breakdown by type in the account settings. They are warned there and in the media archive when usage reaches 80% and again at 95% of the allowance.
At the allowance, new uploads are refused with 413, code
QUOTA_EXCEEDED, and a message stating the usage and the allowance.
An upload is also refused when it would not fit in the space left.
Nothing stored is ever deleted to make room. When seats are removed
and usage ends up above the new allowance, every file is kept and
uploads stay refused until usage is below the allowance again, by
deleting files, adding seats or adding extra storage.
Rights and credit
Images and audio share one rights model:
copyright: the copyright line.credit: the agency or provider to credit.photographerfor images,recordistfor audio: the person who made it.instructions: the provider's directions, such as "Editorial use only during the election".usageTerms: the formal licence terms.usage: what the asset may be used for, scope by scope. Social platforms, paid placement, and edits (crops, overlays, text on top) are each allowed, not allowed or unknown, and unknown until someone says otherwise. A licence expiry and the territories it covers can be recorded too. The image and audio views set the scopes and the expiry.
A document is marked as restricted when it has instructions or usage terms, is marked as AI-generated, has a use that is not allowed, or its licence has expired. The flag is worked out from those fields and cannot be set by hand; because an expiry passes on its own, it is worked out each time it is read. The editor and the media archive show a warning on restricted items, with the text behind it. Systems that republish media should show restrictions just as visibly, at the moment of use.
Publishing an article with restricted images. When a member moves
an unpublished article into usable or withheld from the status
menu, directly or through an AI step that ends there, and the article
embeds restricted images, the newsroom first lists each of those
images with its usage terms, instructions and the uses that are not
allowed. Publish anyway goes ahead;
Cancel leaves the article where it was. An image whose rights
cannot be loaded within a few seconds is listed too, marked as not
checked.
The confirmation is an editorial acknowledgement, not a ban: the
server does not refuse the move, and only the status menu asks. Each
Publish anyway is recorded in the article's private section, in
internal.meta.rightsAcknowledgements, with the time, the member, the
status and the ids of the images shown. Like the rest of the private
section, the record is never published. See the document
reference.
Rights on public copies. The built-in public site serves copies of images, never the uploaded files. A copy carries none of the file's own metadata (EXIF, IPTC, XMP, comments, embedded thumbnails), so location, camera serial numbers and owner names are not published. It carries the image document's rights fields instead:
| Field | XMP | IPTC (JPEG copies) |
|---|---|---|
copyright |
dc:rights |
CopyrightNotice |
credit |
photoshop:Credit |
Credit |
photographer |
dc:creator |
By-line |
usageTerms |
xmpRights:UsageTerms |
not written |
IPTC values are cut to the standard's maximum lengths; the XMP values
are complete. instructions are directions to the newsroom and are
not written. A copy carries the rights recorded on the image when the
copy was made. SVG images, such as site logos, are published as
uploaded, without rights metadata.
Framing and people. An image can carry a focal region, drawn on the image in its view: the part that must stay in frame when the image is cropped to another shape, such as a vertical video. People shown in an image can be flagged as a minor, a victim or someone promised anonymity, for the whole image or for a region of it. These flags are editorial working data in the image's private section and are never published. In a rendered video, a flagged person is blurred wherever the image is shown: their region, or the whole image when no region is marked, becomes a coarse mosaic of a few colours taken from the picture, the same in every frame, so the file does not hold the detail. See the document reference.
Provenance and signatures
AI generation. aiGenerated is true (AI-generated, shown with a
badge), false (declared not AI-generated) or absent (unknown). It is
taken from the file's metadata where present, and members can change
it.
C2PA. A C2PA manifest that comes with an upload is kept, with its issuer and claim generator, and stored next to the file for anyone who wants to validate it. The platform does not issue C2PA manifests of its own and does not judge which issuers to trust.
Platform signatures. On upload, the platform signs the original bytes with Ed25519. Images, audio and video use separate signing domains, so one signature can never pass for another. A missing signature means signing was unavailable at upload time.
Verified transcript segments. When an editor verifies a transcript segment, the platform signs that segment's text and timing and records a hash of the signed text. If the text is edited afterwards, the segment shows that it needs verifying again.
Webhook deliveries list the images, recordings and audio quotes an article uses, with each file's signature, so a receiver can check them. See Signatures and the webhook reference.
Location data. The derived image versions carry no embedded metadata, so GPS coordinates are not passed on through them. The original keeps its metadata, and the location is also stored on the document. Images on the built-in public site are copies that keep only the rights fields, as described under Rights and credit.
Rendered videos
A video made from a video project is a core/video of its own, with
one file per shape (9:16, 4:5) and preset.
- A named person approves the exact version. Export renders only a version a member approved after previewing it in every shape to export. Any change to the project, its assets or the brand kit makes a new version that needs its own approval.
- Every line is checked against the article. Each scene names the article sentences it rests on, and a source check compares them: quotes word for word and given to the person the article quotes; numbers, amounts, dates and times by value; names, inflected forms allowed; and qualifiers such as "allegedly" or "according to police", which may not be dropped, nor an accused person called convicted. A wrong quote, number or qualifier blocks the approval until it is fixed. A name not in the article, a scene that may say more than its sentences, and a scene long for the screen are warnings: the approver may set one aside with a reason, which is kept with the approval. The check reads Spanish, Swedish, English and Portuguese articles.
- A script drafted with AI is recorded. The approval names the
model that wrote it, and the rendered video's
meta.aiDisclosure.scriptModeldoes too. AI that only wrote the script, approved by a named person, needs no label on the video itself; a synthetic voice is always disclosed. - Rights are checked at export. An image or recording that may not be used on social platforms, or whose licence has run out, is refused. One whose social use nobody has recorded needs the approver's acknowledgement, which is kept with the approval.
- The date and the outlet are on every scene, and the closing card lasts under two seconds. The outlet is the public site's name, or the organisation's name when the site has none; with neither, the video cannot be exported.
- Each file is signed over its bytes; see Signatures.
- Withdrawal. A withdrawn video is no longer served: its files
answer
410 Gone, and a notice replaces it where it is shown.
Reading files
Each file has two stable addresses, one for members of the organisation and one for integrators:
GET /api/images/<id>/<version> on the application host
GET /api/audio/<id>/<version>
GET /api/videos/<id>/<version> an uploaded clip: original, poster or preview
GET /api/videos/<id>/renditions/<shape>?preset=<preset>
GET /v1/media/images/<id>/<version> on the public API host
GET /v1/media/audio/<id>/<version>
Both answer with a redirect to a storage link that expires within 10
minutes. A rendered video's shape is 9x16 or 4x5, its preset
default or whatsapp; download=1 asks for an attachment. Clips
and rendered videos are served to members only. Follow the redirect at once and do not store the link; the
stable addresses themselves do not expire.
- The
/apiaddresses serve any file of the organisation to its signed-in members. - The
/v1/mediaaddresses serve a file to an API key of the same organisation with thepublisher:readscope, and only while an article in statususableorwithhelduses the file. Files used only by drafts, planning items or assignments stay private. ThereadUrlof each file in a webhook delivery is its/v1/mediaaddress for theoriginalversion. The exact contract is in the API reference.
Deletion
Members with the owner or admin role can delete an image or a
recording. Deletion is immediate and permanent, and cannot be undone.
There is no recycle bin.
Deleting removes the content from everywhere the platform keeps it:
- the file, its derived versions and its signature;
- the document, with its metadata, caption, credits and, for a recording, its transcript and speaker names;
- every earlier version and every signed snapshot of the document;
- the record of where the file is used, its duplicate record, and the bodies of AI requests and responses about it;
- an image's copies on the built-in public site.
Its storage is released. What remains is a record that a document with this id and type was deleted, when, and by whom, without any of its content. The id stays reserved and cannot be reused.
An image or a recording cannot be deleted while an article in status
usable or withheld uses it. The delete is refused with 409,
code IMAGE_IN_USE or AUDIO_IN_USE, and error.details lists those
articles (documentId, documentType, title, status). Remove the
file from those articles first. Draft and cancelled articles, planning
items and assignments do not block a delete. Signed snapshots already
delivered stay valid as the historical record of what was published;
copies a receiver keeps are theirs to delete.
Articles and planning items are not deleted. They are archived by
moving them to cancelled, which can be reversed. See
Workflows.
Deleting the organisation deletes all of its media.