Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.sys.acorn.programmer > #6226

Re: question music file type

From Jean-Michel <jmc.bruck@orange.fr>
Newsgroups comp.sys.acorn.programmer
Subject Re: question music file type
Date 2020-11-17 12:34 +0100
Organization Jean-Michel
Message-ID <513bccd058.jmb@jmc.bruck.orange.fr> (permalink)
References <eef17dc658.jmb@jmc.bruck.orange.fr> <d25a5cd058.harriet@bazleyfamily.co.uk>

Show all headers | View raw


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

Back to comp.sys.acorn.programmer | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

question music file type Jean-Michel <jmc.bruck@orange.fr> - 2020-10-28 12:17 +0100
  Re: question music file type Harriet Bazley <harriet@bazleyfamily.co.uk> - 2020-11-16 15:12 +0000
    Re: question music file type Jean-Michel <jmc.bruck@orange.fr> - 2020-11-17 12:34 +0100
      Re: question music file type Harriet Bazley <harriet@bazleyfamily.co.uk> - 2020-11-17 14:50 +0000

csiph-web