AROS World Exec
Distros => Icaros Desktop => Topic started by: miker1264 on November 23, 2021, 03:24:15 PM
-
After working with Sound Datatype Conversion for a short while I've concluded that we need more datatypes!
Maybe MOD, MED, MIDI, OGG, MP3 & WMA to start.
We already have WAV & 8SVX.
But the AROS DatTypes System for Sound Files has some issues. It seems Wave has its own datatype but 8svx datatype only has a Load Function. But Wave can save using DTWM_RAW and 8svx can also save a copy of itself. So save functions for AIFF & 8SVX must be included in Sound Datatype Sound_Write.
There are two problems that I've discovered. DTWM_RAW saves correctly. Open an 8svx in MultiView then choose Save As. It saves a complete copy of the 8svx file. But if we try Save As IFF it fails to write an IFF-8SVX file. I suspect there is something wrong inside Sound_Write for Sound Datatype.
There's another problem. It seems the Sound_New should be able to return an empty sound datatype object but it keeps failing. So I suspect there is a problem with Sound_New. But getting a sound datatype object of an existing file does work.
I have more research to do... 8)
-
8SVX It is a data subtype of the IFF file container format, in fact the tested conversion program saves an 8SVX with IFF extension !
-
8SVX It is a data subtype of the IFF file container format, in fact the tested conversion program saves an 8SVX with IFF extension !
8SVX is the Commodore Amiga IFF-8SVX file format. I suspect Save As in MultiView for sound files should save 8SVX with 8SVX or IFF file extension. But AIFF is the Apple Audio IFF which should have its own datatype. It isn't Commodore-specific.
First I must figure out how to make MultiView method DTWM_IFF to trigger Sound_Write which calls Write_AIFF or Write_8SVX. We'll see which format it saves. I suspect 8SVX. Then I'll look at Sound_New. Both functions in Sound Datatype.
-
Interesting. If you open a wave file in MultiView and select Save As IFF it will fail. But if you open an 8svx file and do the same it will succeed in saving an 8svx file. So why the difference?
DTM_Write message is sent to Sound Datatype. In Sound_Write it only examines that write mode. So it considers DTWM_RAW the same as DTWM_IFF. The only caveat is later in the write function it decides the output format based on input format. There are only two options: AIFF & 8SVX. So if the input is 8svx and we choose Save As IFF ( DTWM_IFF ) it will save 8svx. But there is no provision for saving any other format as 8svx.
-
Interesting. If you open a wave file in MultiView and select Save As IFF it will fail. But if you open an 8svx file and do the same it will succeed in saving an 8svx file. So why the difference?
[/quote,
I think it's due to Multiview "going crazy", once we tell it that an "IFF" is an image then we tell it that a music file is also "IFF", I think this creates the conflict.
If you try to give this command:
DTConv Test.Wave sound.8svx sound iff -> you will get a "corrupted" ILBM file
-
AMIGASYSTEM
When you open the resulting IFF file in a Hex Editor what does it say at the top? I suspect it has an ILBM icon because it has an IFF file extension. Either the file is empty ( 0 bytes ) or not valid.
-
No the file is recognized even without extension.
The is not an empty file, it is a hybrid file as big as Wave, but it is not a sound :)
-
That looks like an empty IFF file. :)
Anyhow...problem solved. The scientific method at work. 8)
MultiView can now open a Wav file and Save As IFF to save an 8SVX file.
There were actually two problems. In Sound Datatype the Sound_Write function is the SuperMethod. Normally a datatype has two methods: OM_NEW & DTM_WRITE. The first links the Load function of the datatype with Datatypes Library for getting new datatypes. The second links the Save function of
the datatype or if DT Write Method is not DTWM_RAW then it is supposed to defer to the SuperMethod.In this case it would send the DTWM_IFF message to the Sound Datatype function Sound_Write.
But as I mentioned earlier the Sound_Write function in Sound Datatype doesn't have an allowance for DTWM_IFF only DTWM_RAW. So I added a new method for Sound Datatype as follows in dispatch.c:
if( dtw->MethodID == DTM_WRITE && dtw->dtw_Mode == DTWM_IFF )
{
dbug( kprintf( "My dtw_Mode = DTWM_IFF\n" ); )
D(bug("[sound.datatype] - My dtw_Mode = DTWM_IFF\n"));
err = WriteSVX( cb, o, iff, id );
}
So if the DT Write Method is DTWM_IFF I'm forcing it to convert and save as an IFF-8SVX file.
The second problem I already alluded to...the Wave Datatype DTM_WRITE method was missing some important information. It was missing the part that sends it to the SuperMethod in Sound Datatype.
else
{
/* Pass msg to superclass (which writes an IFF-8SVX sound file)... */
return DoSuperMethodA( cl, obj, (Msg)msg );
}
After those two minor changes I can now open a Wave file and Save As IFF-8SVX. Nice! 8)
-
Notice that there are only two files in Ram Disk - the Wave file I saved with MultiView Save As and the 8SVX file I saved with MultiView Save As IFF when I opened the original Wave file.
-
Just so you can't say but how do you know it saved an 8SVX file and not an imposter hybrid ?
-
Here are the compiled 68k datatypes that I used to open a Wave file in MultiView and save 8SVX with Save As IFF.
Temporarily rename your older sound datatype & wave datatype. Then just copy these two new ones to your Classes/Datatypes.
So open a Wave file and give it a try. :P
-
Just so you can't say but how do you know it saved an 8SVX file and not an imposter hybrid ?
Mine was just a guess, I add that DTConv x86 version doesn't generate that file, it just creates a 0 byte file
Thanks for the new version which I will test shortly.
-
Here are the compiled 68k datatypes that I used to open a Wave file in MultiView and save 8SVX with Save As IFF.
Temporarily rename your older sound datatype & wave datatype. Then just copy these two new ones to your Classes/Datatypes.
So open a Wave file and give it a try. :P
I will test it. Thanks
-
One set of problems done. Now I'm trying to find out why getting an empty sound datatype object from basename fails.
So I placed more debug messages in sound datatype in Sound_NEW to confirm the problem then try to fix it as well.
Not sure if you can see near the bottom of the output screen - Error! Object Creation Failed.
Sure enough! It fails to return a sound datatype object. Now I must find out why. ;)
-
we trust in you :)
-
we trust in you :)
Thanks. This one is a little perplexing at the moment.
It fails to return an empty datatype object but it successfully returns a datatype for an existing file! Hmmm...
But Save As IFF for Sound Files works in MultiView! ;)
But I think I'm close to a solution. Looking at BMP datatype and other standard datatypes when creating an empty object the OM-NEW leads to the Load Function. In turn the Load Function tests for DTST_RAM as opposed to DTST_FILE and it looks for an empty filehandle. If it finds DTST_RAM & an empty filehandle it's an empty object so it returns the empty datatype object as requested.
However we unfortunately only have two sound datatypes for AROS those being Wave Datatype & 8SVX Datatype. So I examined 8SVX datatype first looking at OM_NEW & Read8SVX. But the Read Function doesn't test for DTST_RAM & an empty filehandle. Instead it says If(sourcetype != DTST_FILE) ... return FALSE; So the datatype simply fails to return anything in that case. That's wrong!
After examining Wave Datatype OM_NEW it also doesn't test for DTST_RAM & an empty filehandle. Hence the problem of not returning an empty sound datatype object. Mystery solved? We'll see. ;)
I will modify 8SVX Datatype first then recompile and test again. If it returns an empty datatye...then problem solved.
-
Good news!
After I modified both 8SVX & Wave datatypes to return empty objects I was able to use DTConv to convert 8SVX to Wave.
Making some progress. ;)
The next step is to incorporate the ConvertPicture & ConvertSound into MultiView for Converting Datatypes..
-
After working with Sound Datatype Conversion for a short while I've concluded that we need more datatypes!
Maybe MOD, MED, MIDI, OGG, MP3 & WMA to start.
We already have WAV & 8SVX.
The old 68k versions of AHI for AmigaOS 3 came with a Protracker MOD datatype in 68k Assembly with source. Also included was a Filesave driver to export any audio to an AIFF recording. Maybe that could be of some use. It's all open source.
The datatype system on AmigaOS prior to version 4 on PPC didn't support streamed formats nor does the IFF standard fully. Maybe AROS should follow suit with a child of the base class for streamed audio formats. Maybe it could even wrap all the methods of the Tapedeck gadgetclass.
I've got one other idea for MIDI and modules. I wanted to write a capture AHI driver that could capture the output of any music program to a hybrid format between MIDI and MOD formats. It would store the samples at the beginning using 8SVX, 16SV or even a Raw sample variant like a mod file. Then it would record the commands set for each voice by intercepting the AHI command calls and hashing out the duplicates on every tick. There would be separate playlists for each voice stored to the file but once the channel closed, it would write out the contents of the hashed commands as enumerated structures. This format could capture any module format and reduce it to such simplicity that it could reduce to a copper-based register feeder on chipset-capable Amigas or export to C source directly on other systems.
I started the last idea myself back in college in 2007 but did it wrong. I tried converting Protracker formatted modules to C source but the hardware banging driver was too unstable for the multitasking and had to use mix mode on UAE.
-
@Samurai_Crow
"I started the last idea myself back in college in 2007 but did it wrong. I tried converting Protracker formatted modules to C source but the hardware banging driver was too unstable for the multitasking and had to use mix mode on UAE."
That seems like a nice project to finish. Lots of good ideas. :)
I have a few small projects I'd like to finish as well. Time marches on and sometimes they get left behind.
I believe there is a MIDI datatype already. I haven't looked at it. As for MP3 there is library mpega for conversion. Just an idea.
-
@Samurai_Crow
I believe there is a MIDI datatype already. I haven't looked at it. As for MP3 there is library mpega for conversion. Just an idea.
MIDI should be possible based on Timidity. The hard part of streaming MP3s from a datatype is that it loads the entire file into RAM before it processes it. I don't know how AROS does it but AmigaOS 4 had to add an API change to allow streaming of portions of a file instead.
-
Hi Samurai_Crow, I don't know if I understood correctly, I'm not an expert developer like you, on AROS the MP3 streaming works well with MPlayer.
Regarding MIDI on AROS there is a "wildmidi" Player that works very well only it works only on command line, it doesn't support play from Icon and it doesn't have a GUI. I think that a Midi.datatypes would allow Multiview to play also a Midi.
-
HarmonyPlayer works well with midi files, timidity must be installed :)
-
Thanks, I don't remember that HarmonyPlayer plays Midi files, but it is not associated to an icon, every time for a Midi file you have to open the program first and then load the file.
When you have to test or listen to Midi files from different paths, you need a Player with a small and simple GUI to play directly a Midi file with one click either from Wanderer or from a Filemanager.
-
ok i understand :)
-
You can always create a button in Dopus that launches the program :)
-
It doesn't change anything from Wanderer, moreover from Dopus4 co HarmoniPlayer the Commands included in the Icon Tooltypes are not executed ! so it can't open the GUI !
-
i understand :-\
-
Hi Samurai_Crow, I don't know if I understood correctly, I'm not an expert developer like you, on AROS the MP3 streaming works well with MPlayer.
That's not the problem. The problem is that the file identification rules require access to the whole file. This means that Datatypes.library has the entire 5+ MiB MP3 file sitting in RAM before it even tries to play it. Once it is playing, there are no problems. Only the MP3 file identification problem is there. Streaming assumes that the whole file doesn't NEED to fit in memory at a time. Datatypes aren't aware of that type of file streaming. It's reasons like that that the Anim file loads into RAM before it starts to play even though the file is large. IFF is not streaming aware and Datatypes.library was designed around the idea that importing to IFF would be all that was needed.
-
Thanks for the reply
-
No problem. Sorry for the late response though, I only skimmed over your post earlier and only just now realized that you needed further explanation.
-
Datatypes aren't aware of that type of file streaming. It's reasons like that that the Anim file loads into RAM before it starts to play even though the file is large. IFF is not streaming aware and Datatypes.library was designed around the idea that importing to IFF would be all that was needed.
Uhm... would you be able to elaborate on that (from a technical point of view).
Because to my knowledge iff anim is per definition a good example of how different chunks put together one after another makes it a fairly good candidate for streaming. There even exist a delta packing for one frame to another in order to reduce filesize.
Even the supported iff libraries has provision for it by offering functionality to load one chunk at a time.
Admittingly, you can only be sure the file in it's whole is a valid iff-anim file when parsed entirely. But that is also true for mp3.
But perhaps i have my facts with regards to datatype and iff library mixed up as it has been a while since i worked on these things, if so then please feel free to correct.
-
@magorium
This has more to do with datatypes than IFF. Datatypes.library, as originally implemented, will load the entire file into RAM before it tries to identify it. For MorphOS they essentially replaced many datatypes with Reggae classes capable of streaming files. AmigaOS 4 made a minor change in the Datatypes.library implementation to support streaming. I don't know if AROS followed the AmigaOS 3.1 example or not but I hope it didn't because streaming is not supported by the AmigaOS 3.1 datatypes.
-
Thank you very much for the clarification Samurai_Crow.
afaik Aros follows the same road as classic did/does. Odd that such memory restricted platform would opt for such an implementation. Then again it was probably enough for the time when it was conceived/implemented.