[Finished] MP2 Music Part - Why "BASS-Player"? (1 Viewer)

[Helios61]

Hi Team!

I think MP2 is a very forward-looking, innovative product. I noticed, that at this point of development the music-part is a little bit rudimentary, that is why I decided to extend my future testing on the music-part of MP2. For me the following points are very important and i hope, it is possible to add them to one of the upcoming releases:
1. WASAPI support to playback HiRes-audiofiles. More and more dealers now sell HiRes files (96kHz-24bit, 24bit-88kHz, 2- and multi-channel ...) and I believe a high quality product such as MP2 should be able to play these kind of files.
2. A user-friendly, powerful, and flexible database system. After 6 years since i've been using MP1, i am still using the shared view in MP1 . (BTW, all my files are tagged proper (2TB. Flac, 90% classical music).

Furthermore, i wonder why MP2 still uses the BASS player, because the LAV package is able to play almost all formats (tested with graph studio). Unfortunately I have not managed to activate bitstreaming for audio files.

If there is something new for testing or if you need some test files, please let me know!

Best regards
Michael

 

[chefkoch]

I am not sure about the plans of the other developers, but afaik nobody is planning to do major reworks on the music player parts within the next months. I expect the focus on the eyecatching things like the navigation and the presentation (meta data, fanarts, visualization, ....). The playback is basically working, no wasapi, but imo personal opinion, there are other things that needs to be done first.

Re Bass vs. DirectShow (LAV)
Besides playback we use bass also for accessing audio cds (I know these are nineties ), so it's not only about the file formats.
But I like the idea and it might be worth taking a closer look at it some time.

database system
MP2's metadata storage is very powerful and flexible, it allows storing all the metadata independently of the media itself, like audio, video or the specific ones movies and tvshows. It can be used by a games/emulator plugin to store it's metadata about systems and even games.
It's only required to design / develop the mediaaspects and the tables are created automatically according to the classes.
Here I also see some potential improvements, not all the data is stored as normalized as it could (should?) be: i.e. The series info is stored for each episode, iirc. Nevertheless I did not investigated this very close, yet.

navigation, views and filters
When using MP1 I felt similar like you do. I almost never used any views or filters nor sorts. It took always to much time to find the correct media, so I used the shares view. I guess this was not related to the database storage itself, but more to the navigation and how the available data is filtered and presented.
Here we also have some limitations with MP2 currently.

• currently we do not store the filters that were used before
• the selected item is not stored and re-selected when going back to a previews navigation level (or getting back from fullscreen video to navigation)

We already know about many of the issue which you will noticed when testing MP2's music part, and most of them are generic, that means these apply not only to the music part, but also the movie and tv show part, all the navigation is done by the media part.

"Hmm, if there is nobody working on the music player and the navigation issues are known, what can I do?"
Most the things about what's being done and which priority it has is my personal opinion. So if anybody else wants to work on it and improve, rework or add new features, he is more than welcome todo it and to work on anything that he would like to.

file format support & user stories (test scenarios)
I also think we are lacking a lot of documentation currently. Most of them is useful for developers (they know how it should work), tester (they know what to test/focus) and users (they know how to use it and/or what's possible and supported).

file format documentation
When I improved the movie and series metadata extractors for mkv and the online scrapers earlier this year I started to work out a tag mapping page in wiki: i.e. audio, see also the others there. These pages are mainly focused on the metadata storage and retrieval. When I noticed that we carry the optimFrog.dll with MP2, but do not read the ofr files when importing media, I realized that we also need kind of a file format mapping and overview. I started one at my own wiki space, but had no time lately because of the JIRA preparations, I also expect I won't be able to continue to work on it this year.
Nevertheless imo it is essential to document what MP2 is capable of currently and what not. Which things are supported by bass or LAV and which not.
For this it would be useful to have a recommended test scenario / instructions and for each file format we could link / provide one or multiple sample files.
I remember a page where hundreds of samples have been available, but can not find it currently. Not sure if it was hosted at VLC or MPC.

The tests, test results and documentation would then focus on the two separated parts: import of metadata vs. playback support, because these are in independent components of MP2 (metadata extractors vs. players)

Another huge task I could imagine are user stories in terms of navigation:
Documenting, structuring and categorizing these would be very helpful to understand

• how things actually should work,
• the default / most commonly used views and filters
• which things needs to be configurable / customizable, but here are also different levels i.e.
  • customizable, but these will not be defined in GUI via remote (too complicated): These might be the filter and view schemes in general: defining a view's default sort order, default selected item (first vs. first unwatched), definition of the filter schemes: i.e. series > season > episode, music > albumartist > album > tracks, music > genre > albumartist > album > tracks, music > genre > favouritealbums > tracks, ......
    This way everybody can define his most favorite views and have them available easily. While this might need a separated editor, which is it not about now, it is mainly required for defining the default views.
  • (maybe, but not sure: configurable in GUI's configuration area: Not being able to define such views in deep, as it would be very complicated, but maybe building up new view schemes from the available views. Or enabling and disabling right within the GUI)
  • selectable in GUI: Of course, it should be possible to change the views, filters, sorts on demand while browsing the media. This is already possible. But is there anything missing? Could be improved,

Hmm, what a long post, I think I wanted to write something else, but I am currently not sure what it was
In end: We know many things are not implemented, yet.
I also guess that some features won't be done within the next months because the current devs focus on other features first.
But every constructive feedback, improvement suggestions and support in terms of development, testing and especially documentation are very welcome.

And the better the missing things are structured and described, the easier it is for a developer to implement them and the better is the result in terms of quality.

 

[MJGraf]

Hi Michael!

Welcome to the MP2 testing task force and thanks a lot, we really Need every helping Hand we can get!

2. A user-friendly, powerful, and flexible database system. After 6 years since i've been using MP1, i am still using the shared view in MP1 . (BTW, all my files are tagged proper (2TB. Flac, 90% classical music).

The database System we have in MP2 is already incredibly flexible - but I'm not quite sure what you mean with "user-friendly" in that context. To give you a short Impression:
In MP2 every media item (i.e. every Music file, Video file, picture, etc.) has one or more media item aspects. Every aspect has one or more attributes, which are stored in the database. For example: Every media item has a "MediaAspect", in which all the attributes are stored that are common for all media items (such as the Title of the media item, the Rating, a comment, the playcount, etc.).
Then there is a specific AudioAspect, which is stored for every media item that is an Audio file. There we have attributes like Album, Artist, Genre, etc.
For a complete list of attributes in the AudioAspect, have a look at the source: (https://github.com/MediaPortal/Medi...aManagement/DefaultItemAspects/AudioAspect.cs)
No Need to be scared - you will quickly see that it is easy to understand (at least regarding what is saved in the database for the AudioAspect).

As you can also see, adding addidional attributes to an aspect, is just adding two or three lines of code. That's in principle it. If you add an Attribute to an aspect, all the handling of the database (i.e. creating the respective database field) happens automatically.
Of course you have to fill the new Attribute with values, which is handled by the metadata extractors - and you also Need to make sure that the respective fiels is displayed in the Skin.
But from the Point of view of extensibility, the database is absolutely flexible. Chefkoch e.g. already added a mantis (or better Jira...) about adding MusicBrainz IDs to the AudioAspect. This is a great idea, as I e.g. have all my files tagged with MusicBrainz. So there is already the MusicBrainz ID in the MP3 and FLAC files, which would then be stored in the database. The Advantage is, we could have a MusicBrainzMetadataExtractor. That means, if there is something corrected on the MusicBrainz site (e.g. a typo), this could be automatically corrected in the MP2 database (of course not in the tags of the file, because we don't touch the files themselves).

Chefkoch also has written down all his thoughts about Music metadata in the wiki:
http://wiki.team-mediaportal.com/2_MEDIAPORTAL_2/8_Contribute/Development/3_Concepts/Metadata_system/1_MediaAspects/2_Audio?highlight=MP2 tag

So please feel free to test. Oh, and btw: With your huge Music collection, you could run into the database size Limit of the Standard MSSQLCE database. If this happens, you can try the MySQL database Provider or the SQLite database Provider.
Just let me know if you Need further help!

Michael

 

[Helios61]

The playback is basically working, no wasapi,

IMO thinking in this direction is the wrong way, because, if i have understood correctly, MP2 isn't a "basic" media Center and to be honest, WASAPI isn't something special, it is already supported by a lot of products (XBMC, JRiver and the most Audio-Players for windows and of course MP1)
There is a huge Difference between WASAPI and DS, comparable to the difference between SDTV (Das Vierte (in Germany)) and HDTV 720p (ZDFHD).

Best regards
Michael

 

[tourettes]

There is a huge Difference between WASAPI and DS, comparable to the difference between SDTV (Das Vierte (in Germany)) and HDTV 720p (ZDFHD).l

Difference is not as big as between SD and HD. It highly depends on the setup of the setup and played material if there is differenfce. For example playing CD content on when audio device is configured in OS as 44.1Khz 16bit stereo there wont be much what the OS mixer is doing - just passing the audio to the drivers. For others setups the difference is much bigger.

Currently MP2 is not focusing on the playback quality, so any hi-fi guys should probably still stick with MP1 until MP2 catches on the quality area.

 

[Spragleknas]

Maybe you can help change that?