Tidenda

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 standard variant), 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.
  • photographer for images, recordist for 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.scriptModel does 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 /api addresses serve any file of the organisation to its signed-in members.
  • The /v1/media addresses serve a file to an API key of the same organisation with the publisher:read scope, and only while an article in status usable or withheld uses the file. Files used only by drafts, planning items or assignments stay private. The readUrl of each file in a webhook delivery is its /v1/media address for the original version. 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.