Digital booklets

[bubbleguuum]

(14-04-2013 15:30)simoncn Wrote:  I agree this is a problem. I think the best solution (at least initially) is for the server to send a single value, based on a convention.

As you wish. But the more conventions you add (renaming PDFs, other rules requiring user action), the less this feature will be used.

Quote:I'm fairly uncomfortable with this. The value would presumably need to be in either the proprietary minimserver.com namespace or the proprietary bubblesoftapps.com namespace. I'd much prefer to stay with industry standard tags.

As you wish again as all the CP needs is the URL, and the means by which it gets it doesn't matter much.

Yes the desc tag would have to use a namespace, probably the minimserver.com namespace. There's quite a bit of media servers using desc tags: WMP (to send custom ratings among other things), foo_upnp (to send a dump of all tags and restore them in a foo_upnp client), Twonky (I think).

upnp:lyricsURI maybe standard but you can be assured virtually no CP makes uses of it. And hijaacking it for pdf booklets is debatable...

Anyway it doesn't really matter as long as the pdf URL is transmitted.

[simoncn]

(14-04-2013 15:10)bubbleguuum Wrote:  How pdfs are associated to albums is entirely the reponsability of the media server as the control point only care about the URL.
To make things simple on your end for a first version I suggest associating a booklet to an album only if the containing folder has a pdf.
That covers the vast majority of use case I believe.

Some albums don't have a single containing folder. The booklet conventions would need to handle this situation. I agree that this is up to the server to decide.

Quote:Serving pdf booklets is IMHO not much different that serving album art jpg or png. You could deny all file serving requests of unknown file extensions that are in one of the contentDir's. That's what BubbleUPnP is doing as it is able to serve subtitles (.srt and others) but deny arbitrary forged file requests.

It would be possible to do filtering on specific filetypes. Another option is to serve everything underneath the content directory, but serve nothing that isn't underneath the content directory. This seems like a simple rule for the user to understand when organizing his/her data.

[magister]

(14-04-2013 14:47)simoncn Wrote:  How would you suggest MinimServer should decide which of these two .pdf files should be associated with the <upnp:lyricsURI> tag?

I'm not a programmer and know nothing about the inner workings of the UPnP spec, so there may be possibilities that I am ignorant of. That said, the only thing I can think of this is:

Establish a convention that there will be one PDF file per folder/album, for the booklet. In the rare situation where a user wants to store other PDFs in the same folder, the filename must begin with an arbitrary character such as an underscore (I think underscores are legal in all OS's) or a series of characters such as 'ex_' (for 'extra PDF'). Any PDF files that begin with the special character(s) would be ignored when the server looks for a booklet.

The situation I described with my files from eClassical is not common, so asking users in such situations to rename the non-cover file seems reasonable and won't bother most people.

David

[simoncn]

(14-04-2013 17:24)magister Wrote:  I'm not a programmer and know nothing about the inner workings of the UPnP spec, so there may be possibilities that I am ignorant of. That said, the only thing I can think of this is:

Establish a convention that there will be one PDF file per folder/album, for the booklet. In the rare situation where a user wants to store other PDFs in the same folder, the filename must begin with an arbitrary character such as an underscore (I think underscores are legal in all OS's) or a series of characters such as 'ex_' (for 'extra PDF'). Any PDF files that begin with the special character(s) would be ignored when the server looks for a booklet.

The situation I described with my files from eClassical is not common, so asking users in such situations to rename the non-cover file seems reasonable and won't bother most people.

David

Thanks for this suggestion. It would work if all files for an album are in the same folder (which need not be the case) and if the user follows the convention of having only one .pdf file in this folder that isn't prefixed by an underscore.

I'll give some thought to how these other situations could be handled. Any other comments or suggestions from anyone are welcome.

[classical11]

Thanks everyone for the replies and especially to Simon and BubbleGum for considering implementing this so quickly!

magister's point about multiple PDFs for various bookets made me think of a few more use cases that would need support for multiple PDFs:
- Opera librettos. Some opera CDs do not have the libretto in the main CD booklet but needs to be downloaded separately.
- Sheet music (i.e music scores). Since these need to be purchased separately (or downloaded for free in the case of the public domain ones), it's quite likely that they would be stored in more than 1 PDF for each album since there won't be a one-to-one correlation between the album and the sheet music.

Having the ability to read the score for the music piece that is currently playing would be a great addition that would go beyond what physical CDs currently give you (you can of course look up the physical sheet music separately but that is an extra step).

I understand that this might not be implemented in the first release but it's probably worth keeping in mind for the future.

I agree that it would be ideal to follow standards. The <upnp:lyricsURI> tag sounds like the best way to implement this. Especially since, from what I understand from BubbleGum, the UPnP allows you to send multiple of these tags so additional use cases can be implemented at some point.

[classical11]

(14-04-2013 17:49)simoncn Wrote:  

(14-04-2013 17:24)magister Wrote:  I'm not a programmer and know nothing about the inner workings of the UPnP spec, so there may be possibilities that I am ignorant of. That said, the only thing I can think of this is:

Establish a convention that there will be one PDF file per folder/album, for the booklet. In the rare situation where a user wants to store other PDFs in the same folder, the filename must begin with an arbitrary character such as an underscore (I think underscores are legal in all OS's) or a series of characters such as 'ex_' (for 'extra PDF'). Any PDF files that begin with the special character(s) would be ignored when the server looks for a booklet.

The situation I described with my files from eClassical is not common, so asking users in such situations to rename the non-cover file seems reasonable and won't bother most people.

David

Thanks for this suggestion. It would work if all files for an album are in the same folder (which need not be the case) and if the user follows the convention of having only one .pdf file in this folder that isn't prefixed by an underscore.

I'll give some thought to how these other situations could be handled. Any other comments or suggestions from anyone are welcome.

For albums split into multiple directories, I can think of 2 situations:
- the album spans multiple CDs but it has the same title and is merged by Minim
- the album is part of a box set for which there is only a single large booklet

For both of these cases I store the booklet in the parent folder. Minim could first look in the current folder (where the music files are) for the booklet (that matches the agreed naming convention). If it doesn't find it, it could try to find it in the parent folder.

[simoncn]

(14-04-2013 21:32)classical11 Wrote:  For albums split into multiple directories, I can think of 2 situations:
- the album spans multiple CDs but it has the same title and is merged by Minim
- the album is part of a box set for which there is only a single large booklet

For both of these cases I store the booklet in the parent folder. Minim could first look in the current folder (where the music files are) for the booklet (that matches the agreed naming convention). If it doesn't find it, it could try to find it in the parent folder.

It's possible to split an album's tracks between any number of different folders. MinimServer will merge these tracks if the mergeFolderAlbums property is set to 'true'. Some MinimServer users have set their ripping software to arrange things this way if an album contains tracks by different composers or artists. Also, MinimServer doesn't assume any parent/child relationship between folders.

I'll give this some more thought over the next few days.

[simoncn]

(14-04-2013 21:23)classical11 Wrote:  Thanks everyone for the replies and especially to Simon and BubbleGum for considering implementing this so quickly!

magister's point about multiple PDFs for various bookets made me think of a few more use cases that would need support for multiple PDFs:
- Opera librettos. Some opera CDs do not have the libretto in the main CD booklet but needs to be downloaded separately.
- Sheet music (i.e music scores). Since these need to be purchased separately (or downloaded for free in the case of the public domain ones), it's quite likely that they would be stored in more than 1 PDF for each album since there won't be a one-to-one correlation between the album and the sheet music.

Having the ability to read the score for the music piece that is currently playing would be a great addition that would go beyond what physical CDs currently give you (you can of course look up the physical sheet music separately but that is an extra step).

I understand that this might not be implemented in the first release but it's probably worth keeping in mind for the future.

I think you have convinced me that any solution must include support for sending multiple PDF resources.

Quote:I agree that it would be ideal to follow standards. The <upnp:lyricsURI> tag sounds like the best way to implement this. Especially since, from what I understand from BubbleGum, the UPnP allows you to send multiple of these tags so additional use cases can be implemented at some point.

I checked this in the UPnP specification. It isn't legal to send multiple <upnp:lyricsURI> tags. However, there is another tag named <dc:relation> that can appear multiple times. This latter tag is probably a better choice.

My current thinking is to send <dc:relation> tags for all PDF files that appear in the same folders as any tracks of the album, and let the control point decide what to do with these.

[bubbleguuum]

(14-04-2013 22:01)simoncn Wrote:  My current thinking is to send <dc:relation> tags for all PDF files that appear in the same folders as any tracks of the album, and let the control point decide what to do with these.

Another possibility is to use <res> tags. This is already used by several media servers to transmit subtitle URLs for video items (there's no standard for subtitles either, so there's at least 3-4 methods that I know of, for media servers to send them).

For example it could be:

Quote:<res protocolInfo="http-get:*:application/x-pdf:*">some url here</res>

There can be as many such res tags as pdf booklets. They would have to be placed after all audio <res> tags. The mime-type (application/x-pdf) indicates a booklet.

In fact this would be my preferred solution. I don't like the idea of using lyricsURI much as it can be genuinely be used by a server to send lyrics.

[simoncn]

(14-04-2013 22:12)bubbleguuum Wrote:  Another possibility is to use <res> tags. This is already used by several media servers to transmit subtitle URLs for video items (there's no standard for subtitles either, so there's at least 3-4 methods that I know of, for media servers to send them).

For example it could be:

<res protocolInfo="http-get:*:application/x-pdf:*">some url here</res>

There can be as many such res tags as pdf booklets. They would have to be placed after all audio <res> tags. The mime-type (application/x-pdf) indicates a booklet.

In fact this would be my preferred solution. I don't like the idea of using lyricsURI much as it can be genuinely be used by a server to send lyrics.

Unfortunately, some control points can't handle this. MinimServer 0.70 is sending an additional <res> tag for the album art file in some cases, and eLyric fails to play these tracks because it thinks the album art is the audio file (even though I have used the correct protocolInfo settings). Because of this, I am removing this additional <res> tag in MinimServer 0.71.

I agree that using <upnp:lyricsURI> is a bad idea because it prevents the intended use of this tag.

What do you think about using <dc:relation>?