-
-
Notifications
You must be signed in to change notification settings - Fork 63
4. FAQ (Frequently Asked Questions)
Integration
OK, I've downloaded the library. Now what ? Where do I start ?
Development
What are Dummy classes used for ?
There's something wrong with the library but I have no useful output on the Console. Why so ?
Really, some sections of the code could be better if XXX
Misc.
Is there a way to make ATL write ID3v2.2 tags instead of ID3v2.3 or ID3v2.4 ?
Windows Explorer can't display embedded pictures I saved using ID3v2 Why ?
I'm not happy with ATL performance. Is there a way to improve it ?
You might want to read the Usage / Code snippets section of the documentation to get started with using ATL in your project.
I'm not interested in contributing to ATL and I need the XXX feature for my app. When will the XXX feature be implemented ?
You are welcome to use the Issues area to suggest and discuss new features.
Is there any way to see ATL in action on a specific music collection before integrating the library ?
I'm maintaining a fully native C# application called Ethos Cataloger, which is based on the latest version of ATL .NET. You're welcome to download it, scan your own audio files and even export the results on multiple output formats.
DummyReader and DummyTag are used whenever ATL does not know how to read data (e.g. no parsable metadata in DTS files / trying to read an unsupported audio format with ATL)
ATL has been designed
- to crash as silently as possible if something goes wrong during parsing, to make mass-processing easy
- to redirect useful runtime information to your own logging system
As a consequence, many runtime issues are logged by the ATL logger rather than by standard Console output. The easiest way to display that is :
1/ Copy/paste ConsoleLogger.cs from the ATL.benchmark project to your project
2/ At initialization time, call ConsoleLogger log = new ConsoleLogger();
3/ That's it ! Console output now logs ATL activity, which should hopefully help you see what's going wrong
ATL .NET is a project I'm maintaining during my free time, with the knowledge I've acquired by personal research on C#/.NET features and digital audio. I know it's not perfect, but it reaches its primary goal, i.e. scanning thousands of tracks from my music library in a matter of seconds.
Anyway, you're welcome to fork and submit any improvement, or discuss design and implementation choices on the Issues area.
Help ! I don't know anything about programming, I just want to read XXX data from my audio files and write it into a list
You might be interested in using Ethos Cataloger, which is based on the latest version of ATL .NET. You're welcome to download it, scan your own audio files and export the results on multiple output formats.
If you really need ID3v2.2 support, please tell me about it and explain why
By default, older versions of ATL (< v3.00) allowed to write picture descriptions using non-western characters (japanese, cyrillic...), which breaks compatibility with Windows explorer (that's quite a random thing to say, but it's true !)
Counting from v3.00, ATL encodes picture descriptions with the Latin-1 charset by default, which ensures that pictures do show up on Windows explorer !
You can tweak that behaviour with Settings.ID3v2_forceAPICEncodingToLatin1 (default : true)
You can tweak the following global parameters :
-
Settings.FileBufferSize: a higher buffer size uses more memory but reduces the number of I/O operations. Recommended values are between 128 and the size of the file you're manipulating. -
Settings.ForceDiskIO: perform all I/O operations directly on disk when updating tags instead of using a buffer. Reduces RAM usage but increases disk usage. Not recommended on slow storage (SD card, network drives)
If you're working on big files stored on slow storages, you may gain performance by copying the file locally (i.e. on the main device's fast storage), editing it there, and copying it back to its initial location once editing is done. You'll likely avoid tons of network overhead.
If you're distributing your app as a Flatpak package, the sandboxing systems make file I/O much slower. Enabling --filesystem=home on flatpak allows I/O speed to match that of a locally run version.
For any other issue regarding performance, feel free to open an issue on the tracker.