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)

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)

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)

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)