Comments (20)
Sorry, I've been working on my other project all week long. I'm gonna take a look ASAP 😅
from atldotnet.
Readonly values in IDictionary<string, string> AdditionalReadOnlyFields
Also I'd make the type IReadOnlyDictionary
from atldotnet.
The WAV thing is a coincidence - you actually discovered a bug where removing an AdditionalField
has no effect on some WAV chunks. The fix will ship with next release ✅
I still have to implement "solution B". Will do that during the weekend.
from atldotnet.
Done! Available on today's v5.12 👍
from atldotnet.
Yay! Thanks :)
from atldotnet.
you're welcome. Sorry for the two-weeks lag 😋
from atldotnet.
I agree about VORBIS-VENDOR
.
However, I don't see how or why info.ISFT
would be mandatory or unmovable. Did you confirm that using ATL?
from atldotnet.
However, I don't see how or why info.ISFT would be mandatory or unmovable. Did you confirm that using ATL?
Yes same code as with VORBIS-VENDOR, just with loading a WAV file instead and obviously removing info.ISFT instead.
info.ISFT field contains Lavf60.3.100
(codec information) just like VORBIS-VENDOR does and therefore shouldn't be considered an Additional Field but mandatory instead.
from atldotnet.
Could instead of hiding them from AdditionalFields, we have a ReadOnlyAdditionalFields list that would contains these properties? That why they will still be available for us to show to user but ensure that they aren't altered.
from atldotnet.
Hi, any update on this?
from atldotnet.
Sorry, I've been working on my other project all week long. I'm gonna take a look ASAP 😅
No worries, I've been swamped with midterms and school work this week so I understand 😆
from atldotnet.
Here are my first thoughts on the subject :
- I understand the link you've made between
VORBIS-VENDOR
andinfo.ISFT
as they are similar in the information they carry (referring to properties of the physical audio data).
However, there's a structural difference between them : theVORBIS-VENDOR
field is built in the Vorbis format and is completely mandatory, whereasinfo.ISFT
is an optional field that is absent from many WAV files
That also means track.AdditionalFields.Remove("info.ISFT")
should work perfectly 😉
-
I think it wouldn't be wise to remove this information from
Track.AdditionalFields
as it is as useful as any other metadata -
Marking specific metadata as read only or undeletable would be the correct way to go theoretically, but embedding that information would require to change the type of
AdditionalFields
from its currentIDictionary<string, string>
to something more elaborate... and less intuitive to use. As we're talking about just one metadata, I'm not convinced the case is big enough to change this widely-used data structure.
Maybe transmitting a second IDictionary<string, MetadataProperties>
would do the trick?
from atldotnet.
That also means track.AdditionalFields.Remove("info.ISFT") should work perfectly 😉
I'm going to do some more testing and provide you with the file that it wasn't working on if I can still reproduce it...
from its current IDictionary<string, string> to something more elaborate... and less intuitive to use. As we're talking about just one metadata, I'm not convinced the case is big enough to change this widely-used data structure.
maybe IDictionary<string, (string Value, bool ReadOnly)>
as a tuple.
Maybe transmitting a second IDictionary<string, MetadataProperties> would do the trick?
I feel like having a second Dictionary here with a same information is a waste of space.
Maybe a IReadOnlyList<(string Title, string Value)> AdditionalReadOnlyFields
list with just the read only properties to avoid having to modify the original AdditionalFields list?
I feel like making the original AdditionalFields list a IDictionary<string, (string Value, bool ReadOnly)>
is the most intuitive solution. Yes it breaks API but it's still just one list/dictionary instead of requiring extra memory space.
from atldotnet.
Breaking an important part of the API and making it harder to use for just one single metadata still feels overkill to me. I'm thinking of all the other apps that use the library. Such a change would be far from neutral to them... plus you can't be serious about extra memory, we're talking bytes 😅
I'm hesitating between :
A/ Values in IDictionary<string, string> AdditionalFields
; properties in IDictionary<string, MetadataProperties> AdditionalFieldsProperties
- Pros : Best retrocompatibility + can enrich
MetadataProperties
when we need to document more properties than "read only" - Cons : Weird design : having to synch two data structures to get a piece of information has never been a good sign
B/ R/W values in IDictionary<string, string> AdditionalFields
; Readonly values in IDictionary<string, string> AdditionalReadOnlyFields
- Pros : Crystal clear purpose for each Dictionary + allows to easily ignore read-only fields at write-time
- Cons : Silent retrocompatibilty issue; minor code adaptation is required to get all additional fields again + we're stuck if we want to add more properties to our metadata
My personal preference would go to B anyway. How about you?
from atldotnet.
My personal preference would go to B anyway. How about you?
I agree that B is the best solution to go with.
from atldotnet.
That also means track.AdditionalFields.Remove("info.ISFT") should work perfectly 😉
I'm going to do some more testing and provide you with the file that it wasn't working on if I can still reproduce it...
Here's the WAV file that contains info.ISFT
and in which the code does not work: https://go.wetransfer.com/t-EvR5H2NAYQ
Again the code used is:
var track = new Track(Path); //wav file
track.AdditionalFields.Remove("info.ISFT");
track.Save();
track = new Track(Path) //reload
var x = track.AdditionalFields.Contains("info.ISFT"); //x is true
from atldotnet.
I just realized that, even though "VORBIS-VENDOR" is technically mandatory (in the sense that the field has to be in the file structure), the Vorbis spec doesn't forbid :
- to change its initial value
- to set it to "" (i.e. empty string), which would count as a functional delete
Right now, the latter doesn't work by calling track.AdditionalFields.Remove("VORBIS-VENDOR")
but I can fix this easily. Wouldn't that fix the whole issue?
from atldotnet.
Right now, the latter doesn't work by calling track.AdditionalFields.Remove("VORBIS-VENDOR") but I can fix this easily. Wouldn't that fix the whole issue?
Yes I get that would work too.
from atldotnet.
you're welcome. Sorry for the two-weeks lag 😋
No worries...I've been lagging with all my school work too so no rush 😅
from atldotnet.
Can confirm it's fixed. Thanks again!
from atldotnet.
Related Issues (20)
- wav file duration is not determined HOT 2
- OptimFROG blind tags HOT 6
- long .ogg file loading HOT 3
- more understandable name HOT 6
- Chinese encoding exception HOT 6
- Reading MP3 files whose ID3v2 tags contain multiple PRIV frames HOT 14
- Doesn't work with .mp4 HOT 13
- track artist has invisible spaces? HOT 8
- Feature Request: Adding support for writing /mp42/isom m4a tags HOT 6
- Re-creating Track.AdditionalFields causes tag duplication HOT 3
- Issues when reading/modifying MP4 files containing MDAT atoms with 64bit lengths HOT 15
- Can't add a tag HOT 2
- The `AudioFileIO` reads HEIC file endlessly HOT 6
- Slow performance when re-tagging HOT 2
- Library fails to correctly parse date for flac files with more than one "Year" tag HOT 4
- Insufficient Characters Read HOT 6
- When LRC formatting fails, it results in other fields being incorrect.
- Syntax for writing Cart Chunk metadata? HOT 5
- FLAC files with artwork embedded by ATL fails flac -t HOT 13
- SaveTo() cannot overwrite Audio itself HOT 5
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 atldotnet.