I am using obs to sequentially record many mp4 files. They are stored in a directory under a naming convention of clip_{n}.mp4. A ruby program detects the files in the directory and lists them for the user. However, the second you hit record in obs, the file is already created while it is still being written. So the ruby program detects and incomplete file to list to the user. I am looking for a way to exclude this incomplete file until obs is finished recording and saving the clip. I gave tried using system %Q[lsof #{file_path}] but it is quite slow. Is there any better way to detect an "incomplete" file?
I am building a simple real time delay system on my mac (2010-11 model; os x Mavericks; serial audio input) using Simulinks (Matlab 2014a) consisting of a 'Audio Input' block, an 'Audio Output' block a 'delay' block and an adder (to add the delayed signal to the original signal), but I receive the error: 'Error in 'untitled/From Audio Device': A given audio device may only be opened once.' twice for the audio input block.
When I try the same using a audio file as my input I get the desired results. Also the same diagram works fine on a windows machine.
Please help.
Thank you.
I think the issue is that you are trying to output a sound to the audio device, while at the same time to trying to read from the audio device. That won't work, you can't do that. See Keep playing a sound over and over again in Matlab? for a similar issue in MATLAB. You need to somehow wait for the reading part to complete before outputting the sound back to the audio device, or use two different devices, one for reading and one for writing.
I suspect the same model worked on a Windows machine because it probably had two audio devices (maybe a built-in and an external), and the model automatically detected this, reading from one device, and outputting to the other. The documentation for both blocks says:
Use the Device parameter to specify the device from which to acquire
audio. This parameter is automatically populated based on the audio
devices installed on your system.
which again, reinforces that theory. If you still have access to the Windows machine, you can double-check that this is the case.
I am using an external soundfont to play MusicStrings and everything is working find. When I use player.saveMidi(etc, etc) the files are saved with the original MIDI soundfont.
Soundbank soundbank = MidiSystem.getSoundbank(new File("SGM-V2.01.sf2"));
Synthesizer synth = MidiSystem.getSynthesizer();
synth.open();
synth.loadAllInstruments(soundbank);
Player player = new Player(synth);
Pattern pattern = new Pattern("C5majw C5majw C5majw");
player.play(pattern); // works fine with external soundbank
player.saveMidi(pattern, filename); //Doesn't save with external soundbank instruments
Is there any workaround or built in feature that supports this functionality?
Thanks!
Keep in mind that MIDI is a set of musical instructions. Regardless of whether you load a soundbank into the Java program, when you save as MIDI, you're only saving musical instructions. (By "musical instructions", I mean things like "NOTE ON" or "INSTRUMENT CHANGE" but not actual musical sound data)
It sounds like what you want to do is render your music into a WAV file using the sounds from the soundbank that you have loaded. To do this, you'll want to use the Midi2WavRenderer available here: http://www.jfugue.org/code/Midi2WavRenderer.java
I'd like to be able to open a file on Windows Phone 7, in an XNA game, without reading the entire file into memory. I'm trying to stream audio from WAV files, to be passed to DynamicSoundEffectInstance for playback.
The method I have now uses TitleContainer.OpenStream() to open the WAV file, and then reads it on a background thread using ThreadPool.QueueUserWorkItem(). However, this causes a hitch at the beginning, and today I verified that TitleContainer.OpenStream() returns a MS.Internal.InternalMemoryStream object, which would suggest that it's reading the entire file into memory in OpenStream().
This is corroborated by the fact that it seems to take effectively no time (or, only a memcpy()'s worth of time) to do the Read(), and that Stream.BeginRead() (which is included on WP7 as part of the Async CTP) calls its callback before returning.
Is there any way to open a file on WP7 XNA without reading the entire thing into memory? If not, this is completely ridiculous.
There does not appear to be a way to do this. However, since I know the size of the chunks I want to read (32kB), I can split the files into chunks offline and read them one chunk at a time.
To restrict the scope, let assume we are in Windows world only.
Also assume we don't want to play with permission policy.
Is it possible for us to create a file that cannot be copied?
Thank you in advance.
"Trying to make digital files uncopyable is like trying to make water not wet." ~ Bruce Schneier
No. You can't create a file that a SYSADMIN can't copy. You could encrypt it, though.
Well, how about creating a file that uses up more than 50% of the total space on that machine and that is not compressible?
For instance, let us assume that you want to save a boolean (true or false) in such a fashion.
Depending on its value, you could then write a bit stream of ones or zeroes and encrypt said stream using some kind of encryption algorith, such as AES in CBC mode. This gives you the added advantage of error correction. Even in case of massive data corruption, you should be able to recover your boolean by checking whether ones or zeroes are prevalent in the decrypted stream.
In that case you cannot copy it around (completely) on the machine...
Of course, any type of external memory that can be added to the system would pose a problem in this scenario. But the file would be already encrypted, so don't worry about it too much...
Any file that can be read can have its contents written to another location (such as another file, i.e. copied).
The only thing you can do is limit who/what can read the file.
What is the motivation behind? If it is a read-only file, you can have it as embedded resources within your assembly.
Nice try, RIAA.
But seriously, no you can not. It is always possible to copy, you can just make it it more difficult for people to make sense of the file or try to hide it using like encryption. Spotify does it.
If you really try hard thou, you cold make a root-kit for windows and use it to prevent windows from even knowing about the file and also prevent copies. The file will still be there and copy-able by other tools, or Linux accessing the ntfs.
If in a running process you open a file and hold an exclusive lock, then other processes cannot read the file until you close the handle or your process terminates. However, as admin you could forcibly remove the lock handle.
Short answer: No.
You can, of course, use security settings to limit who can read the file. But if someone can read it, then they can copy it. Even if you found some operating system trick to disable "ordinary" copying, if someone can read the file, they can extract the contents, store it in memory, and then write it somewhere else.
You can encrypt the contents so it's only useful to your own program, that knows how to decrypt it.
That's about it.
When using Windows 7 to copy some files from a hard drive, certain files popped up a message saying they could not be copied in their entirety; certain data would be omitted from the copy. I suspect that had something to do with slack space at the end of the files, though I thought the message was curious. I would have expected the copy operation to just ignore the slack space.
If you are running old (OLD) versions of windows, there are certain characters you can put in the filename that make it invalid, not listed in folders, etc. They were used a lot in the old pub ftp days of filesharing ;)
In the old DOS days, you used to be able to flag disk sectors as bad and still read from them. This meant the OS ignored the sector in question but your application would know where to look and be able to get the data. Not sure this would work these days.
Another old MS-DOS trick was to put a space character in the middle of the filename (yes, spaces were valid characters for filenames). Since there was no method on the command line to escape a space, the file couldn't be copied using the DOS commands.
This answer is outside Windows so yeah
Dont know if its already been said but what about a file that is an inseperable part of the firmware so that it is always on AND running, perhaps it has firmware that generates a sequence that is required for the other . AN incedental effect of its running is to prevent any 80% or more of its code from being replicated. Lets say its on an entirely different board, protected by surge protectors, heavy em proof shielding and anything else required to make it completely unerasable.
If its possible to make a program that is ALWAYS on and running as long as the copying software is running then yes.
I have another way and this IS with windows. I will come to your house and give you a disk, i will then proceed to destroy every single computer you put the disk into. This doesnt work on XP
Well technically you could create and write to a write-only network share.