This Library Is Awesome! You did a Great Job! ^_^

[glowysourworm]

I'm wondering a little bit about who-is-who in the world of Tag Codecs. You mentioned in your readme file that there's a reason to use this library over tag-lib. I can name 1000 reasons; but it shows that you really cared about this code base. So, thanks very much for doing that!

There have to be a small handful of hobbyists in charge of: tag-lib; chroma-print; music brainz; VLC; ATL; etc... And, what I want to know is what's happening with these types of libraries. Did people migrate to Java a while back? What are the current to-do's and plans for audio processing for .NET (or Java)? How many people do you work with; and do you have a roadmap? what other developments are there? Are these highly dependent on proprietary formats (that are currently changing?) I've tried implementing an M3U parser (for example) and the de-facto standard gets a little silly with all the wanted format-features in the X- (ext standard). Although, I managed to import about 2 million of the total radio stations on the github (consolidated) streaming radio list. (I'm not sure how many there are, actually). But, I've since found RadioBrowser to be "good enough"; and fully featured.

(related)
I see you also have an M3U parser. I would wonder if it will ever be detailed moreso than you need for a local streaming radio implementation. Or, is it needed for reading mp3 streams, or acc streams, to gather details from streaming radio stations?

So, one of the features I needed from tag-lib was an interface specification. I'm seeing IMetaData gives almost everything from a typical mp3 tag. So, I'm going to utilize this facade and your Track class to do what I was doing with tag-lib (I'm in the process of migrating). One other thing I'm wondering is about 3rd party information. Usually, I see Music Brainz, Amazon, and a couple other 3rd party segments inside the tag. So, I'll see whether these come through using the user-extended field list you provided. If not, it's probably not the end of the world, just another couple fields to add to the database side.

I sense that you left it to the users to finish what would be a complete property-UI side data facade. Is there any plans to complete these? How many formats total do you need to do the work for? Do you need people to finish this?

Thanks again. Looking forward to seeing your library in action! :)

[Zeugma440]

I'm wondering a little bit about who-is-who in the world of Tag Codecs. You mentioned in your readme file that there's a reason to use this library over tag-lib. I can name 1000 reasons; but it shows that you really cared about this code base. So, thanks very much for doing that!

Well, thanks for the kind words ! 😄

There have to be a small handful of hobbyists in charge of: tag-lib; chroma-print; music brainz; VLC; ATL; etc... And, what I want to know is what's happening with these types of libraries. Did people migrate to Java a while back? What are the current to-do's and plans for audio processing for .NET (or Java)?

I'm not sure I can answer for the maintainers of these projects. From what I can perceive, some of these projects are doing fine while others are kinda lagging behind for reasons we can only guess. I'm not sure technology has anything to do with all that - each programming language / framework has its own landmark audio libraries; there's no "competition" between two libraries from different languages afaik, except maybe very specific cases (e.g. the big move from Java to Kotlin).

How many people do you work with; and do you have a roadmap? what other developments are there?

As you can see on my stats, I'm the main contributor and I've been receiving precious help from everyone who post issues and PRs.

Right now there's no roadmap - I'm fixing issues as they appear, adding new formats from time to time as I discover them, and perform the occasional refactorings for the health of the codebase.

Are these highly dependent on proprietary formats (that are currently changing?)

Not sure I understand what you mean here - most formats ATL supports have specifications. Those that don't have been implemented by looking at online documentation and retro-engineering.

I see you also have an M3U parser. I would wonder if it will ever be detailed moreso than you need for a local streaming radio implementation. Or, is it needed for reading mp3 streams, or acc streams, to gather details from streaming radio stations?

Could you be more precise about that ? Right now, the M3U parser does a basic job; the use case is reading and editing your everyday playlist.

If you have documentation about what's needed for a local streaming radio, I'd be happy to take a look at it.

One other thing I'm wondering is about 3rd party information. Usually, I see Music Brainz, Amazon, and a couple other 3rd party segments inside the tag. So, I'll see whether these come through using the user-extended field list you provided. If not, it's probably not the end of the world, just another couple fields to add to the database side.

Yep, all that's not present as a named field in IMetadata behaves as documented on https://github.com/Zeugma440/atldotnet/wiki/Focus-on-non-standard-fields

I sense that you left it to the users to finish what would be a complete property-UI side data facade. Is there any plans to complete these? How many formats total do you need to do the work for? Do you need people to finish this?

If you mean Facade as in the design pattern, Track is what you're looking for. It's a unique class designed for all-purpose uses that hides inner classes complexity.

If you mean a complete one-to-one mapping between any known audio metadata and the library, this is definitely not something I'm planning to do. The reason is we might be able to acheive it for documented, "standard" metadata, but not for custom metadata (e.g. specific fields inserted by a programmer for the specific needs of his software). This custom metadata will continue to need a generic structure a la "non-standard fields", which leads us back to where we are now =D

[glowysourworm]

Hey @Zeugma440 , thanks for your reply. I see that your Track is the base for this library, thanks again. As far as M3U support, I'm not dictating what to do, here. The way to get at it is to see what's written, probably for a while. So, it would take some of us to read the Wikipedia, actually. The Apple standard is in there; and it's a few hundred pages, I think - which is why I said thanks for your hard work! We need to be more explicit about standards, us hobbyists..... >< ^^

I can at least say, one of the problems I didn't want to deal with was multi-file support for M3U's - which was one of their "features". So, like, you have a directory folder, then you have to put together a playlist based on that. So, it's almost like a hidden-directory-file sort of design. I'm expecting that Apple, or someone, did parts with their implementation - which is why it even matters. There's no real reason this standard should hold water for the rest of us.

Anyway, I have essentially built what you've built for an M3U Parser. So, I'd rater rid it from my code base, and just use ATL; but I may just stick it in my ATL fork for a while, and see if the standard is going to matter. I'll let you know if there's anything you might want; and I may just put what I have in my fork.

There are some cool methods for implementing parsers. Have you ever used Antlr before?

[Zeugma440]

I can try to fathom what this "multi-file support" is, but I need a starting point, like a specific M3U file with those multi-file markers inside.

Looking for "multiple files" or "multi file" inside RFC 8216 doesn't find anything. Can you give me pointers?

Have you ever used Antlr before?

Nope, but I'm happy to discover it. Thanks for the suggestion.

[glowysourworm]

The wikipedia mentions it here: https://en.wikipedia.org/wiki/M3U

"Apple used the extended M3U format as a base for their HTTP Live Streaming (HLS)[12] which was documented in an Independent Submission Stream RFC in 2017 as RFC 8216.[13] Therein, a master playlist references segment playlists which usually contain URLs for short parts of the media stream. Some tags only apply to the former type and some only to the latter type of playlist, but they all begin with #EXT-X-."

An example where it's ambiguous: #EXTM3A | playlist for tracks or chapters of an album in a single file

Contrasted with: #EXT-X-MEDIA-SEQUENCE (another playlist indicator)

It would appear that playlists may extend from one file to another, which means we're going to have trouble until someone has actually spent time and read the entire standard, understood it, and implemented it. I'd ask around, and make a few friends - maybe VLC has done this before. It would be something expected of a big / mutli-platform media player.

Antlr is a parser generator program to build computer language parsers, syntax analyzers, and interpreters, for generic language grammar. If you spend about 1-2 hours, you can build a C# interpreter, or a JSON syntax highlighter, or even (maybe) an M3U parser - if someone built the grammar (file) for it. I have a project that's using Antlr to build a simple C interpreter, and eventually, a small device compiler (you have to add the Assembler for this part). Might be worth looking into.

[Zeugma440]

An example where it's ambiguous: #EXTM3A | playlist for tracks or chapters of an album in a single file

Fun fact : I can't seem to find any single sample playlist containing #EXTM3A. Are you certain it's an actual issue for you?

That one looks like a vendor-specific field (https://birdcagesoft.com/)

Contrasted with: #EXT-X-MEDIA-SEQUENCE (another playlist indicator)

Some interesting things I found :

• Thorough article about HTTP Live Streaming : https://www.linkedin.com/pulse/everything-you-need-know-http-live-streaming-hls-rohita-obinendi/
• Sample playlists (I found some of them to be questionable) : https://raw.githubusercontent.com/globocom/m3u8/70ea61b3fa63cbfc1dcb0901a37a8d880d41d0a6/tests/playlists.py
• Demo app for HLS with working sample M3U files : https://hlsjs.video-dev.org/demo/

At first sight, it looks like #EXT-X-MEDIA-SEQUENCE is an optional instruction to explain the client which segment should be played first. I wouldn't focus on that one if I were you.

[Zeugma440]

I'd roughly go with something like this as an HLS interface (pseudocode; not actual C#).

Would that fit your needs?

HLSPlaylist {
	// true : MediaSequences is null; Streams and Medias are populated
	// false : MediaSequences is populated; Streams and Medias are null
	IsMasterPlaylist : boolean
	
	Streams : IList<HLSStream>
	Medias : IList<HLSMedia>
	
	MediaSequences : HLSSequenceCollection
	

	HLSStream {
		Bandwidth : int
		Codecs : string
		Location : string
		AdditionalFields : IDictionary<string, string>
		Medias : IList<HLSMedia>
	}

	HLSMedia {
		MediaType : AUDIO|VIDEO
		GroupId : string
		Name : string
		Default : boolean
		AdditionalFields : IDictionary<string, string>
		Location : string
	}
	
	HLSSequenceCollection {
		AllowCache : boolean
		TargetDuration : int
		AdditionalFields : IDictionary<string, string>
		Sequences : IList<HLSSequence>
		
		HLSSequence {
			Duration : int
			Description : string
			Location : string
		}
	}
}

[glowysourworm]

Also, (sorry), is Winamp open source, and have you ever worked on it? I used to use that when I was in college. That might be a good source of information on "hobbyist libraries". Thanks

[Zeugma440]

Winamp used to be closed source for ages and recently became open source. I haven't felt the need to look at it so far.

[glowysourworm]

Ok, Thanks.