You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- By currently observed, a `.ncm` file may contain duplicated meta tags, coming from both _the NCM file heder_ and the wrapped _audio content_. This component would take all of them and merge together to show distinct values.
4
+
5
+
- Other meta informations such as `codec`, `duration`, `bitrate`... are retrieved by the underlying decoder, typically `FLAC` or `MPEG` decoder. **And the decoder is also reading meta tags of the audio at the same time**. Thats the reason why both source of meta have to be dealed with.
6
+
7
+
- The audio content is **NOT fully decrypted in the memory at once**, but decrypt while reading on demand. This significantly reduces the memory usage, but slightly affects the speed of processing. It may be hard for compilers to optimize the `transform_view`, used in the implementation.
8
+
9
+
## Retagging
10
+
11
+
By design, the music meta information such as title/artist/album etc is embedded and re-encrypted into the `ncm` header. This decision was reached considering the following factors:
12
+
13
+
- The audio content isn't _"clean"_. Meaning if we take the embedded tag of the audio as overwrites, some music might be "polluted" by the tags at the original state.
14
+
15
+
- Audio content is not verified when played by _NCM player_. So there is no way to tell whether it's modified, nor to completely restore the file state.
16
+
17
+
- Replay gain is written to the audio content because it's recoverable and **simply tested** that the file hash will turn back after clearing the custom gain information.
18
+
19
+
- The meta information stored in the `ncm` header is essentially a standard stringified `JSON` object, allowing easy extension while preserving all original fields. Although modifying it would change its identification, causing the _NCM player_ to refuse to playback, it's totally recoverable by deleting the overwrites.
20
+
- An `overwrite` key is **appended** to the `JSON` if user customized the meta tags. All changes would happen in the `overwrite` object.
21
+
-**Clear all tags result in removing the `overwrite` key, which is actually equivalent to restore the file idntification.**
22
+
23
+
Currently, the downloaded `.ncm` files can be recognized and played by the _NCM player_**IF**:
24
+
25
+
- It's put in a monitored directory.
26
+
- The album art or the replay gain is edited, while other meta information isn't.
27
+
- Meta tags are once edited, then cleared by `Remove tags` utility.
28
+
29
+
## Extractor
30
+
31
+
- The extraction menu is unavailable in old fb2k versions (v1.6), due to **API incompatity**.
32
+
33
+
- The extraction process is multi-threaded. Spawn order: `UI => extractor(x1) => worker(xN)`.
34
+
35
+
- The output file would be overwritten if existed, and no warning would be given in this case. See the comments at
36
+
`ncm_file::save_raw_audio()`.
37
+
38
+
## The Behaviors of the _NCM Player_
39
+
40
+
- The meta info JSON is built and writen **AFTER** completing the download of the music file.
41
+
42
+
- The cover image is always retrived from the internet. The player will just ignore the embedded image.
43
+
44
+
- There may be some extra verifications to the identification （`163 key(Don't modify):xxxx`）. The player refuses to play even when off-line.
45
+
46
+
- The player actually recognize `.ncm` files by the identification, not by the decrypted meta info fields.
0 commit comments