• question music file type

    From Jean-Michel@21:1/5 to All on Wed Oct 28 12:17:27 2020
    Bonjour;
    I try to put some music files on my site, but when I get them (!NerSurf)
    the file type is not taken into account, they are typed in Text. https://jeanmichelb.riscos.fr/Rhap4_Scores.html

    The files I upload are Maestro or Rhapsody4 files.
    namming
    Filename/music for Maestro and filename/Rhap4 for Rhapsody4
    I added these lines to the mimemap file and type * readmimemap in a
    taskobey, but no change.

    # Media type 'Music'
    # Private
    music/x-rhapsody4 Rhap4 ad7 .rhap4
    music/x-maestro music af1 .music

    Is this the right method?

    Thanks,

    Note : Rhapsody2 files also have type & C00 and type & AD7 is not in the FileType list
    https://www.riscosopen.org/wiki/documentation/show/File%20Types


    --
    Jean-Michel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harriet Bazley@21:1/5 to Jean-Michel on Mon Nov 16 15:12:35 2020
    On 28 Oct 2020 as I do recall,
    Jean-Michel wrote:

    Bonjour;
    I try to put some music files on my site, but when I get them (!NerSurf)
    the file type is not taken into account, they are typed in Text. https://jeanmichelb.riscos.fr/Rhap4_Scores.html

    The files I upload are Maestro or Rhapsody4 files.
    namming
    Filename/music for Maestro and filename/Rhap4 for Rhapsody4
    I added these lines to the mimemap file and type * readmimemap in a
    taskobey, but no change.

    # Media type 'Music'
    # Private
    music/x-rhapsody4 Rhap4 ad7 .rhap4
    music/x-maestro music af1 .music

    Looking at the existing MimeMap file, I'd guess at a type
    of audio/rhapsody4 or application/x-rhapsody4 being more appropriate,
    but I don't know how the IANA system works. (And, as others have
    commented in the past, entries such as application/vnd.openxmlformats-officedocument.wordprocessingml.document
    are completely unpredictable.)

    From Tim Hill's file:

    # FILE FORMAT:
    # Lines starting with a '#' are comments, blank lines are ignored.
    #
    # A '*' is a wildcard before or after the / or for the RISC OS file type
    # The first match that does not map to a wildcard is the one that is used.
    #
    # If the file type name is not known but a hex value is given that type
    # is used, otherwise it is not considered a match.
    #
    # x- (or X-) denotes an unofficial non-IANA mapping, and should come after
    # the 'official' types in that group.
    #
    # The eight IANA MIME type groupings are:
    # application/ audio/ image/ message/ model/ multipart/ text/ video/
    #


    I tried adding your proposed lines to my Mimemap file as an experiment,
    then doing *readmimemap followed by a *mimemap query, and it appeared to
    have worked:

    *mimemap rhap4
    MIME type: audio/x-rhapsody4, RISC OS file type: &AD7
    Extensions:
    rhap4

    However, I get the same results as you did when attempting to download
    files with an 'extension' of .rhap4 - NetSurf interprets them as text
    files.


    Druck posted on the Messenger mailing list archive: http://www.intellegit.com/support/viewmessage.php?list=messenger-l&id=20201&start=100&max=25

    If the file mappings are not set up correctly on a foreign filing system (HostFS or Lanman98), you'll see the PC file as name/ext but with a
    filetype of text or data. If you open the file with a RISC OS
    application, it will probably set the file type appropriately. On RISC
    OS the file will stilllook like it has the same name (name/ext) but the correct file type.

    However on the foreign filing system, what has happened is the set type
    is actually to name.ext,xyz where xyz is the hex RISC OS file type. To
    avoid this rename, and to make sure that RISC OS sees the correct
    filetype straight away, the MIMEMAP file needs to be set up correctly
    for Lanman98, the DOSMap file for LanmanFS, and the Virtual Acorn file
    type mappings for HOSTFS.

    I don't know if this is relevant in your case.



    But as a more general comment, it seems to me that when you are trying
    to offer files for download over the Internet, it's never going to work correctly unless the *user's* machine has the relevant MimeMap data set
    up - and since this is something over which you have no control (and
    neither Rhapsody4 nor Maestro appear to be recognised by the official
    lists either at the RISC OS end or the IANA end), then uploading them in
    their 'raw' format is not a good idea.

    The most practical approach would seem to me to be to upload Rhapsody
    files as ZIP archives, thus ensuring that the filetypes are preserved
    inside the archive.


    --
    Harriet Bazley == Loyaulte me lie ==

    He who hesitates is last.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jean-Michel@21:1/5 to Harriet Bazley on Tue Nov 17 12:34:35 2020
    Hi,
    In message <d25a5cd058.harriet@bazleyfamily.co.uk>
    Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

    On 28 Oct 2020 as I do recall,
    Jean-Michel wrote:

    Bonjour;
    I try to put some music files on my site, but when I get them (!NerSurf)
    the file type is not taken into account, they are typed in Text.
    https://jeanmichelb.riscos.fr/Rhap4_Scores.html

    The files I upload are Maestro or Rhapsody4 files.
    namming
    Filename/music for Maestro and filename/Rhap4 for Rhapsody4
    I added these lines to the mimemap file and type * readmimemap in a
    taskobey, but no change.

    # Media type 'Music'
    # Private
    music/x-rhapsody4 Rhap4 ad7 .rhap4
    music/x-maestro music af1 .music

    Looking at the existing MimeMap file, I'd guess at a type
    of audio/rhapsody4 or application/x-rhapsody4 being more appropriate,
    but I don't know how the IANA system works. (And, as others have
    commented in the past, entries such as application/vnd.openxmlformats-officedocument.wordprocessingml.document
    are completely unpredictable.)

    From Tim Hill's file:

    # FILE FORMAT:
    # Lines starting with a '#' are comments, blank lines are ignored.
    #
    # A '*' is a wildcard before or after the / or for the RISC OS file type
    # The first match that does not map to a wildcard is the one that is used.
    #
    # If the file type name is not known but a hex value is given that type
    # is used, otherwise it is not considered a match.
    #
    # x- (or X-) denotes an unofficial non-IANA mapping, and should come after
    # the 'official' types in that group.
    #
    # The eight IANA MIME type groupings are:
    # application/ audio/ image/ message/ model/ multipart/ text/ video/
    #


    I tried adding your proposed lines to my Mimemap file as an experiment,
    then doing *readmimemap followed by a *mimemap query, and it appeared to
    have worked:

    *mimemap rhap4
    MIME type: audio/x-rhapsody4, RISC OS file type: &AD7
    Extensions:
    rhap4

    However, I get the same results as you did when attempting to download
    files with an 'extension' of .rhap4 - NetSurf interprets them as text
    files.
    I tried to modify the mimemap file as you suggested but actually as you
    say, the download does not work better.
    I investigated in !NetSurf, it will look for the mimemap file but ignore
    these additions? even after restarting.

    Druck posted on the Messenger mailing list archive: http://www.intellegit.com/support/viewmessage.php?list=messenger-l&id=2020 1&start=100&max=25

    If the file mappings are not set up correctly on a foreign filing system
    (HostFS or Lanman98), you'll see the PC file as name/ext but with a
    filetype of text or data. If you open the file with a RISC OS
    application, it will probably set the file type appropriately. On RISC
    OS the file will stilllook like it has the same name (name/ext) but the
    correct file type.

    However on the foreign filing system, what has happened is the set type
    is actually to name.ext,xyz where xyz is the hex RISC OS file type. To
    avoid this rename, and to make sure that RISC OS sees the correct
    filetype straight away, the MIMEMAP file needs to be set up correctly
    for Lanman98, the DOSMap file for LanmanFS, and the Virtual Acorn file
    type mappings for HOSTFS.

    I don't know if this is relevant in your case.
    I just did a test with my windows pc. I take a Rhapsody file, I change the
    file to T and add the suffix / Rhaps4.
    Then I open LanMan and copy the previous file to the destination
    directory, and there the file appears with the correct icon and the
    correct file type...
    The same test with a maestro file, file type modified in Text, the
    conversion is not done ...
    I checked the mimemap file and added the following line in the Application topic:
    application/x-maestro Maestro af1 ,music
    But unfortunately it does not work. By checking the list of applications I found a line:
    application/riscos * *
    I commented it out and in this case it worked. Ouf!
    But unfortunately no change with NetSurf.

    But as a more general comment, it seems to me that when you are trying
    to offer files for download over the Internet, it's never going to work correctly unless the *user's* machine has the relevant MimeMap data set
    up - and since this is something over which you have no control (and
    neither Rhapsody4 nor Maestro appear to be recognised by the official
    lists either at the RISC OS end or the IANA end), then uploading them in their 'raw' format is not a good idea.

    The most practical approach would seem to me to be to upload Rhapsody
    files as ZIP archives, thus ensuring that the filetypes are preserved
    inside the archive.

    I think this is the right solution, thanks for your reply.

    Regards.


    --
    Jean-Michel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harriet Bazley@21:1/5 to Jean-Michel on Tue Nov 17 14:50:24 2020
    On 17 Nov 2020 as I do recall,
    Jean-Michel wrote:

    [snip]

    I just did a test with my windows pc. I take a Rhapsody file, I change the file to T and add the suffix / Rhaps4.
    Then I open LanMan and copy the previous file to the destination
    directory, and there the file appears with the correct icon and the
    correct file type...
    The same test with a maestro file, file type modified in Text, the
    conversion is not done ...
    I checked the mimemap file and added the following line in the Application topic:
    application/x-maestro Maestro af1 ,music
    But unfortunately it does not work. By checking the list of applications I found a line:
    application/riscos * *
    I commented it out and in this case it worked. Ouf!

    As I understand it, this is a default which applies if none of the other
    lines match - and the lines are read in order from the top, so your new application/x-maestro would have to appear before the general application/riscos line.

    But that is just what I gathered from reading a couple of pages on the Internet. I couldn't find any helpful discussion on this specific
    problem.


    But unfortunately no change with NetSurf.


    I think you probably need to ask about that on the NetSurf mailing list
    to find out how the mimemapping is supposed to work. It would be nice
    to understand how it actually functions.

    But archiving files is always the easiest way to preserve filetype data
    when transferring them via foreign operating systems.


    --
    Harriet Bazley == Loyaulte me lie ==

    When you breathe you inspire; when you do not breathe, you expire.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)