[WIP] "Preparation" and "Writing the script" for Basics and Workflow #21
Conversation
Wrong order and I didn't notice that the additional compression I did on it actually destroyed the picture too much. If any of you know a good way to compress it further without that insane detail loss, please lmk (or compress it yourself).
… and workflow Will probably do the rest of this page at some point, but not right now.
LightArrowsEXE
changed the title
|
|
||
| Some groups have set standards. |
There was a problem hiding this comment.
Except in germany. Because in germany having a standard set by a group implies that there is a group to be a part of to begin with.
* Audio encoding and muxing have now been written. * Added screenshots for Muxing, and an audio file for Audio Encoding.
* Add section on actually encoding the video.
|
For the Encoding the Result section I need some help with sane defaults for x265, as I am not familiar with it whatsoever. |
There was a problem hiding this comment.
I'm a bit confused as to why you're listing the various video defects and artifacts on this page when we already have one dedicated to it. I guess it is needed to go over these to explain the building blocks of a standard script, but it may be better to reference the artifacts from the artifacts page (and add the images there) instead of making this section as long as it currently is.
Anyway, this is a rough review for now.
| They might even only go for | ||
| 8bit colors in the latter case! | ||
| If you're unsure what standards a group has, | ||
| contact your group leader. |
There was a problem hiding this comment.
I'd like to have a sentence that reiterates how this guide focuses on best practices and should generally be preferred over sticking to some weird standards (scene releases any1?).
| contact your group leader. | ||
|
|
||
| There are various sources | ||
| that are often used for the video. |
There was a problem hiding this comment.
The "often" in this sentence makes it seem pretentious.
| that are often used for the video. | |
| that can be used for video and audio material. |
| as those are easy to acquire, | ||
| or Blu-rays, for the improved quality and fixes. | ||
| As a beginner, you might not | ||
| have access to private trackers with BDMVs yet. |
There was a problem hiding this comment.
This sentence seems out of context because you didn't explain beforehand that BDMVs are frequently uploaded to private trackers.
|
|
||
| `Trim` is used for trimming the video. | ||
| It's inclusive, | ||
| which means that it also adds the `last` frame given. |
| These are exclusive however, | ||
| so you need to take that into account. | ||
|
|
||
| Inclusive and exclusive work like this: |
There was a problem hiding this comment.
Imo it should be enough to just claim that the above two trims are equivalent (and skipp the following paragraphs), or do people have problems with the two terms "inclusive" and "exclusive"?
| 148.088.813 KaguyaBD_01_(09)_16bit.flac | ||
| 148.080.093 KaguyaBD_01_(10)_16bit.flac | ||
| 147.368.127 KaguyaBD_01_(11)_16bit.flac | ||
| 147.327.448 KaguyaBD_01_(12)_16bit.flac |
There was a problem hiding this comment.
I don't think we need this many example files for the sake of comparing audio file sizes.
|
|
||
| `$ opusenc input.wav output.opus` | ||
|
|
||
| Unlike qaac, opus works with a constant bitrate. |
There was a problem hiding this comment.
Fwiw, FFmpeg's libopus uses vbr by default, and it is generally reccomended over cbr and cvbr. The -b:a option for libopus uses that number as a vbr estimate by default.
| `$ mkvmerge -o output.mkv input_video.264 input_audio.m4a` | ||
|
|
||
| For a list of all settings, | ||
| check the [documentation](mkvmerge_docs). |
There was a problem hiding this comment.
| check the [documentation](mkvmerge_docs). | |
| check the [documentation][mkvmerge_docs]. |
| *** | ||
|
|
||
| [^1]: "funcs" are a combination of wrappers written by people to perform different tasks. | ||
| Most of these can be found in the [VapourSynth Database][vsdb] |
There was a problem hiding this comment.
Iirc you cannot use linebreaks in footnotes. @OrangeChannel?
There was a problem hiding this comment.
Yea, that's correct.
| You can encode to fLAC using ffmpeg | ||
| with the following command: | ||
|
|
||
| `$ ffmpeg -i input.wav output.flac` |
There was a problem hiding this comment.
These will probably look better in proper blocks. You could also use the {% term %} blocks from a plugin, as shown in CONTIBUTING.md.
Yeah, this is the main reason why. I have a hard time seeing how this guide should be written with the information on how to spot artifacts and a guide on how to actually fix them separated from each other. Seemed far easier to note them down here for people know what to look out for and what filters to use to fix them up, all in one nice spot. |
| as it is designed for | ||
| low-latency, low-complexity audio compression. | ||
| This makes it great for "mini" releases. | ||
| You can encode to qaac through ffmpeg: |
There was a problem hiding this comment.
Typo here, qaac --> opus
| x264: | ||
| * 480p: crf 18 or 19 | ||
| * 720p: crf 15 or 16 | ||
| * 1080p: crf 16 |
There was a problem hiding this comment.
That's a first. I've always seen people recommending lower values for lower resolutions.
| ``` | ||
|
|
||
| AAC serves as a fantastic middleground | ||
| between FLAC and opus. |
There was a problem hiding this comment.
AAC is not "a middleground between FLAC and opus" - it's an alternative to opus, a competitive lossy codec. AAC will only be slightly larger than opus, so it's definitely not any kind of middleground.
| You can set it with `-b:a` in ffmpeg | ||
| and `--bitrate` in opusenc. | ||
| For anime, a bitrate of 128k is usually transparent | ||
| for both dialogue and music. |
There was a problem hiding this comment.
160k is a commonly accepted value for transparency in stereo.
- also includes a fix for a typo in the image scaling section
This is a massive update to the CSS but the only actual change is switching the katex formatting to be identical to in-line and block code. This 'new' CSS is all of the smaller files put together and compacted, making editing/finding any future classes much easier.
masking-limiting-etc: fix formatting
resampling: fix big formatting
So, this has an interesting consequence, that any $$, even within `$$` or code blocks will change to the template shown here. You can print them escaped in-text, but not within back-ticks.
If we were to use GiB instead, the answer still wouldn't have been 5475 kbps as 1Kib != 1Kb: 1Kib is 1.024Kb, so the answer should've been ~5607 kbps. I checked that the DVD size is specified in decimal GB and listed the source. Added the python script too so nobody has to do this manually anymore.
Will probably do the rest of this page at some point, but not right now.