Comments (7)
Sorry, my mistake, the branches were swapped, this is fixed now.
👍 for the initial parsing of the COVERART
/ METADATA_BLOCK_PICTURE
and only writing it during the Render
method call. The FieldCount
property would need changing too, as it is based on the total number of elements in the field_list
dictionary values.
Detecting user changes to the target fields is easy as all field access methods are already implemented (if SetField
/RemoveField
are called for COVERART
or METADATA_BLOCK_PICTURE
, we would then invalidate the current Picture[]
state and parse it again).
The Picture[]
array could be loaded lazily though, to prevent a performance hit on scenarios where lot of files are involved, but only simple text-based tags are being read.
from taglib-sharp.
Good initiative !
I would have a preference for 2.ii. although for 2.ii it is probably simpler to store everything (and convert) in the same TagLib.FLAC.Picture or TagLib.Picture array from the File reading. Then you have only one object class/collection to handle. This should make it also easier for the end-user.
from taglib-sharp.
Thanks for the input!
Currently the XiphComment class only stores a list of string[] which represent the raw field values stored in the file. Although this means there is virtually no need for tracking state (especially if the user uses the GetField and SetField methods directly), property getters and setters can be quite expensive (in the case of the Pictures property, this involves decoding the base64 contents, then allocating data structures, and then parsing the picture data).
I'm also wondering about the classes representing pictures. Aside from a few extra properties in TagLib.FLAC.Picture (width, height, color depth, and indexed color count), TagLib.Picture and TagLib.FLAC.Picture have a lot in common. But Tag.Pictures being of type IPicture[] this calls for some weird "if (picture is TagLib.FLAC.Picture)" code.
Implementations for 2.i and 2.ii, to see what it looks like:
from taglib-sharp.
It seems like 2.ii. still stores both COVERART
and METADATA_BLOCK_PICTURE
...
I think you're right, storing the raw values poses some problems...
In my opinion, the most efficient architecture would be to store only Picture[]
(as a field) in the Tag
.
Only at the end of the File.CreateFile() call you convert all the base64 COVERART
and METADATA_BLOCK_PICTURE
to populate Picture[]
field (and you dispose the former base64 fields). Only in the Tag.Render()
you convert the Picture[]
to the METADATA_BLOCK_PICTURE
.
This way this is faster, the returned list doesn't change every time you call the Picture
Getter, and you gain also in memory usage (as a Base64 is an inefficient way to store data).
That would mean a bit of code-motion but in the end, it gets simpler.
What I mean, is that with current approach, I always find this a bit confusing:
WriteLine("{0}", file.Tag.Count); // --> 1
file.Tag.Picture.Add(myPicOne);
file.Tag.Picture.Add(myPicTwo);
WriteLine("{0}", file.Tag.Count); // --> still 1 !!!
from taglib-sharp.
Implemented lazy approach in vtavernier:metadata-block-picture-lazy
from taglib-sharp.
The Picture[] array could be loaded lazily though, to prevent a performance hit on scenarios where lot of files are involved, but only simple text-based tags are being read.
Hey ! That would be really cool ! Great idea !
If you encapsulate this lazy load into the Picture class, for example by adding a new constructor public Picture (File, long position, long length)
, a lot of other format may make use of it. I'd happily do the Matroska adaption to make use of it. We just must be careful to make sure to read the Pictures before we write these (when calling File.Save()
), otherwise the physical location of the picture we want to write may be already overwritten or shifted in the file under write.
from taglib-sharp.
If you encapsulate this lazy load into the Picture class, for example by adding a new constructor public Picture (File, long position, long length), a lot of other format may make use of it.
This would be very interesting in order to reduce the memory stress while scanning a lot of files. Running a memory profiler on taglib-sharp reveals a lot of allocations of byte[]
objects from ByteVectors
as well as strings. If a solution is implemented for Picture
s, other fields should be able to benefit from it. I think this is out of the scope of this particular issue though.
from taglib-sharp.
Related Issues (20)
- Wrong AudioBitrate at some ogg Files
- NestPlayer
- Access To The Path is Denied
- Creating tag RIFF tags in WAV file
- Id3v2 Tag Does Not Support Podcast Frames
- Error reading tag from Photomechanic
- How do I get the dimensions (height and width) of pictures HOT 2
- Impossible read/write tag software HOT 1
- Files not writeable by Taglibsharp but writeable by other tools HOT 1
- ID3v2 WXXX frame is empty HOT 9
- CombinedTag.IsEmpty returns true if any child is empty rather than if every child is empty
- Save Taging destroys highres wav
- PNG tags not being added HOT 1
- TagLibSharp Corrupting MP4\M4V files when updating Tag.Title HOT 1
- Support for classical music tags introduced in iTunes 12.5
- Cannot set tags for .jpg files HOT 1
- File Not Writeable message when setting data for JPG file
- Release type and Release status showing as null
- Finding the video Codec ID in an MKV file
- [BUG] Corrupted UnknownBox data
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from taglib-sharp.