macOS theoretically possible to create aliases of audio files without needing to point?

[patent10021]

Would there be a way to make Handoff/iCould work in such a way that it wouldn't need the original audio source files? It could make purely graphical aliases without actually needing to point to the original files like normal aliases do. I guess you could call them 'X aliases'.

Is it theoretically possible to create "temporary aliases" of audio files that can't be heard?

An 'X alias' would have to take the original audio file's information and convert it to a visual form (which is what wave forms are anyway) AND ALSO make that data visually malleable and transmutable and then readable by a second computer which has the original audio file and uses that X alias to base the changes of the original audio file on.

X aliases = temporary aliases. Could this be done?

 

[subsonix]

Would there be a way to make Handoff/iCould work in such a way that it wouldn't need the original audio source files? It could make purely graphical aliases without actually needing to point to the original files like normal aliases do. I guess you could call them 'X aliases'.

Is it theoretically possible to create "temporary aliases" of audio files that can't be heard?

An 'X alias' would have to take the original audio file's information and convert it to a visual form (which is what wave forms are anyway) AND ALSO make that data visually malleable and transmutable and then readable by a second computer which has the original audio file and uses that X alias to base the changes of the original audio file on.

X aliases = temporary aliases. Could this be done?

Audio waveforms are not visual unless you present them that way, and using that as a means to store audio would take a lot of space. As an example, one 16 bit sample can store 2^16 values so your image would need to be 65,535 pixels high and 44,100 pixels wide to store one second of audio. That's a large image.

 

[patent10021]

Audio waveforms are not visual unless you present them that way, and using that as a means to store audio would take a lot of space. As an example, one 16 bit sample can store 2^16 values so your image would need to be 65,535 pixels high and 44,100 pixels wide to store one second of audio. That's a large image.

But I don't want to store the audio. Only the graphic representation of it.

 

[subsonix]

But I don't want to store the audio. Only the graphic representation of it.

The point I was trying to make was that if you really want to represent the audio it's going to be much larger than the audio itself, because an image uses a lot of data that isn't useful. For the example above, one second would take about 2.7 gigabytes of data. If you just want a regular image showing a waveform it will be a crude approximation that you can't do anything with except visually inspect.

 

[sero]

The point I was trying to make was that if you really want to represent the audio it's going to be much larger than the audio itself, because an image uses a lot of data that isn't useful. For the example above, one second would take about 2.7 gigabytes of data. If you just want a regular image showing a waveform it will be a crude approximation that you can't do anything with except visually inspect.

Maybe in a vector format?

 

[chown33]

But I don't want to store the audio. Only the graphic representation of it.

What are you hoping to accomplish with this? What problem is this expected to solve?

I don't understand what you're trying to do with Handoff that your description of graphical "X aliases" would be the solution for.

Maybe in a vector format?

Any graphical vector format that maintains full fidelity of the audio samples would be at least the same number of data points as the audio file itself, and quite probably more. At best, a vector format would consist of relative X,Y moves.

In sampled-audio files, X is implicit rather than explicit (it's a sample interval), and is always +1 in the direction of increasing time. That is, given a sample at location n, the sample at location n+1 is the next sample in the time sequence of samples. As a result, no X coordinate, delta, or step value needs to be supplied in the file. In graphics, X isn't implied, unless there's an extremely flexible vector format where you can specify the same X step for a list of Y values.

The graphical Y values would be identical to the original audio samples, or at most be the first difference: x(n) - x(n-1), where n is the sample number.