question music file type

35 views
Skip to first unread message

Jean-Michel

unread,
Oct 28, 2020, 7:17:33 AM10/28/20
to
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

Harriet Bazley

unread,
Nov 16, 2020, 10:19:55 AM11/16/20
to
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.

Jean-Michel

unread,
Nov 17, 2020, 6:35:14 AM11/17/20
to
Hi,
In message <d25a5cd05...@bazleyfamily.co.uk>
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

Harriet Bazley

unread,
Nov 17, 2020, 9:53:17 AM11/17/20
to
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.
Reply all
Reply to author
Forward
0 new messages