caesura 𝄓
An all-in-one command line tool to automate transcoding FLAC or FLAC 24 bit source torrent to MP3 320 (CBR) and MP3 V0 (VBR), then upload to gazelle based trackers.
Features
All gazelle based indexers/trackers are supported
- RED
- [wip] OPS.
Tested on Linux, theoretically works on Windows.
Fully configurable, if there's something hard coded that you think should be configurable then open issue on GitHub.
Source Verification
Each source is verified to ensure:
- A lossless FLAC
- Not a scene or lossy release
- Files match the torrent hash
- Audio tags for artist, album, title and track number are set
- [fixed] Classical sources have a composer tag.
- [fixed] Vinyl track numbering
- Sample rate and channels are suitable
Spectrogram Generation
- Full and zoomed spectrograms generated for review
Transcoding
- [fixed] Multi-threaded transcoding with optional CPU limit
- FLAC and FLAC 24 bit sources are supported
- FLAC, MP3 320 (CBR) and MP3 V0 (VBR) target formats
- Existing formats are skipped
- [fixed] Nested sub directories are fully supported (i.e. CD1, and CD2 etc)
- [fixed] Automatic naming following established conventions, with decoding of HTML entities.
- [fixed] Shorter file names.
- Automatic torrent file creation
- [new] Images in the root and first nested directory are included and all other files ignored.
- [new] Images larger than 750 KB are reduced to less than 1280 px, converted to JPG and compressed.
The logic being that for transcodes only folder and cover images are important. Anyone interested in additional files and high quality artwork can find them in the source torrent.
Upload
- Copy transcodes to content directory
- Copy torrent file to client auto-add directory
Batch
- [new] Verify, transcode and upload with one command for every torrent file in a directory.
The application will crunch through your torrent directory and automatically determine which are FLAC sources suitable for transcoding.
Getting started
Docker is the recommended way to run the application across all platforms.
- All dependencies are built into the image
- Runs in an isolated environment reducing risks to your system
[!TIP] Configuration options and the commands they apply to are documented in COMMANDS.md
0. Install Docker
Install Docker Engine for your OS.
1. Run the help command
Run the help command to see the available commands and options.
[!TIP] You can append
--helpto any command to see the available options.
2. Create a configuration file
Run the config command to print the default configuration and redirect it to config.json.
[!NOTE] You can ignore the "Failed to read config file" warning.
Edit config.json in your preferred text editor. Set the following fields for your indexer:
announce_urlYour personal announce URL. Find it on upload page.api_keyCreate an API key withTorrentspermissionSettings > Access Settings > Create an API Keycontentthe directory containing torrent content. Typically this is set as the download directory in your torrent client. Defaults to./content.indexerthe id of the indexer:red,pth,ops.indexer_urlthe URL of the indexer:https://redacted.ch,https://orpheus.network.outputthe directory where transcodes, spectrograms and .torrent files will be written. Defaults to./output.
3. Verify a source
Run the verify command with the source as an argument.
[!NOTE] Because the application is running in a Docker container, you need to mount the config file, content directory and output directory.
[!TIP] For the source you can use a permalink, the numeric torrent id or a path to a torrent file:
Each step of this guide will use a different source to demonstrate, but feel free to use whichever suits you best.
&torrentid=142659#torrent142659
If it looks good you can proceed to the next step, otherwise try another source.
4. Use Docker Compose
Docker is great but specifying the volumes everytime is tedious and prone to error.
Using Docker Compose simplifies this by storing the configuration in a docker-compose.yml file.
Create a docker-compose.yml file with the following content:
services:
caesura:
container_name: caesura
image: ghcr.io/rogueoneecho/caesura
volumes:
- ./config.json:/config.json:ro
- /path/to/your/content:/content:ro
- ./output:/output
[!NOTE] The
:rosuffix makes the volume read-only which is a good security practice.If you intend to use the
--copy-transcode-to-content-diroption then you must remove the:rosuffix from the content volume.
Now run the verify command again but this time using Docker Compose:
5. Generate spectrograms of a source
Run the spectrogram command with the source as an argument.
Inspect the spectrograms in the output directory.
6. Transcode a source
Run the transcode command with the source as an argument.
Inspect the transcodes in the output directory.
[!TIP] Things to check:
- Folder structure
- File names
- Tags
- Audio quality
- Image size and compression quality
7. Upload transcodes
[!WARNING] You are responsible for everything you upload.
Misuse of this application can result in the loss of your upload privileges.
Run the upload command with the source as an argument.
[!TIP] Ideally you've already checked everything and nothing will go wrong but just in case there is a grace period after uploading in which you can remove the upload from your indexer.
[!TIP] If you're unsure about this then you can append
--dry-runto the command and instead of uploading it will print the data that would be submitted.
&torrentid=142659#torrent142659
Go to your indexer and check your uploads to make sure everything has gone to plan.
8. Batch processing
[!WARNING] You are responsible for everything you upload.
Misuse of this application, especially the
batchcommand, can result in the loss of your upload privileges or a ban.
Now that you have the hang of the application we can speed things up with the batch command.
This handles verify, spectrogram, transcode and upload in a single command. It can also be pointed at a directory containing torrent files to automatically sort through and pick out suitable sources.
By default the batch command will limit to processing just 3 transcodes and it won't create spectrograms or upload unless explicitly instructed. These safeguards are in place to prevent mistakenly uploading a bunch of sources that you haven't checked.
[!NOTE] The batch command uses a cache file to store progress helping speed up subsequent runs.
Make sure the cache file is in a mounted volume so it's not deleted between runs.
Run the command to compile a cache and transcode the first three sources in the directory:
[!TIP] Add the
--spectrogramflag to generate spectrograms.
If everything goes to plan three sources should have transcoded to your output directory.
You can filter the cache file with jq to see what has been transcoded:
|
Or to see what has been skipped and why:
|
If you're working with a lot of files then less can be helpful:
| |
Nothing was uploaded in the first run giving you a chance to check the transcodes and spectrograms. Once you're satisfied run the command again but with the --upload flag (or set "upload": true in the config file).
Check the uploads on your indexer to make sure everything has gone to plan.
Now, we can set the batch command loose with the --no-limit option to transcode (but not upload) every source in the directory:
Once you've checked the transcodes you can start to upload them in batches. The --wait-before-upload 30s option will add a 30 second wait interval between uploads to give you time to check everything looks good, and spread out the load on your indexer:
[!WARNING] In theory you can execute with both
--upload --no-limitbut that is probably a bad idea and a very fast way to lose your upload privileges.If you are going to do so then you should definitely use a long wait interval:
--upload --no-limit --wait-before-upload 2m
Commands and Configuration
[!TIP] Configuration options and the commands they apply to are documented in COMMANDS.md
Configuration options are sourced first from the command line arguments, then from a configuration file.
By default the application loads config.json from the current working directory, but this can be overridden with the --config <CONFIG_PATH> cli argument.
Most options have sensible defaults so the minimum required configuration is:
Recommended configuration
This is based around the setup in this guide: how to set up Deluge via Proton VPN with port forwarding.
Directory structure
/srv/sharedis a shared between multiple containers, by mounting as a single volume hard linking is possible./srv/deluge/stateis the Deluge state directory, containing all.torrentfiles loaded in Deluge./srv/shared/delugeis the Deluge download directory, containing all the content.
config.json
"source": "/srv/deluge/state",inconfig.jsonmeans the source can be ommitted from the command.
docker-compose.yml
user: "1000:1001"ensures files have the same ownership as the host user (use theidcommand to find your user and group id).- Only
/srv/sharedhas write permissions, the other directories are read-only. command: batchruns the batch command by default./is the working directory of the container so mounting the config to/config.jsonmeans it's read by default.
services:
caesura:
container_name: caesura
image: ghcr.io/rogueoneecho/caesura
user: "1000:1001"
volumes:
- /srv/caesura/config.json:/config.json:ro
- /srv/deluge/state:/srv/deluge/state:ro
- /srv/shared:/srv/shared
Troubleshooting
If you encounter any issues:
- Check the logs for errors.
The logging verbosity can be adjusted with the --verbosity <LOG-LEVEL> option. The available log levels are:
warnonly showing warnings and errorsinfowill give an overview of what's happeningdebugprovides insight into each steptraceis detailed logging to see exactly what's happening
- Re-read the getting started guide
- Ask for help in GitHub Discussions
- Create an issue
[!TIP] If you manage to resolve your issue it's always worth creating a new discussion anyway because it might help someone else in the future, or identify an area where the documentation could be improved.
Build
The build process is documented in BUILD.md
Releases and Changes
Releases and a full changelog are available via GitHub Releases.
Release versions follow the Semantic Versioning 2.0.0 specification.
Commit messages follow the Conventional commit specification.
History
DevYukine completed the initial work and released it as red_oxide under an MIT license.
RogueOneEcho forked the project to complete a major refactor, fix some issues, add new features and improve logging and error handling. The fork is released as caesura under an AGPL license.
The main difference between the former MIT license and the present AGPL license is that if you intend to distribute a modified version of the code - even to run it on a server - you must also provide the modified source code under an AGPL license.
This is often known as copyleft. The intent is to ensure that anyone taking advantage of this open source work are also contributing back to the open source community.
The code base has now adopted object oriented patterns with SOLID principles and dependency injection.
See also the list of contributors who participated in this project.