Echoprint “listens” to audio on a phone or on your computer to figure out what song it is. It does so very fast and with such good accuracy that it can identify very noisy versions of the original or recordings made on a mobile device with a lot of interference from outside sources.
I compiled the iOS example provided on the website. So far so good.
Sadly, Echoprint failed to recognize any song via the iPhone's microphone (recording time up to 1 minute).
On the other hand, it was capable of recognizing songs by "uploading" them directly from the iPhone's media library.
Any idea, what the problem could be?
Echo print is not intended to work over the air. At least not with the given configuration. You can adapt the code, focus on the matching functions (best_match), to get some results for over-the-air configuration. The actual best_match function returns a song only if it is really close to the reference, which won't happened with songs recorded with the microphone of your phone. Also consider recording a longer segment.
I think the problem is the sampling rate at which the song is being recorded. If it's at 8 kHz it probably won't work; it has to be at least a minimum of 11 kHz.
Related
I have an app that uses AVPlayer to play live streams and on-demand video. That in-house app (and recent in-house update) plays video beautifully in all sorts of conditions. Until a user in the company updated to iOS 13.
The same app run under iOS 12 from the same location will work perfect as before.
Now, after a reboot of the phone the first video played will play perfect and if it is a live stream will run for an indefinite amount of time without trouble. The second video played will always play audio only or fail depending on the bit rates available for the video. Even the exact same video.
Quiting and restarting the app makes no difference in the results. Restarting the phone WILL fix it for the next video played.
What appears to be happening is that on the first play, observedBitrate in the event log is correct and the correct bit rate stream is played. The second playback shows observedBitrate starting out an order of magnitude less and no reasonable amount of time sees that rate change significantly.
If the connection is an order of magnitude better than necessary (evidently that is true for most of these users including myself pre-Network Link Conditioner testing), then everything appears to work normally and life is good. What is even stranger, is that on these higher quality connections I don't see the same observedBitrate drop. Also, it appears that video served up from a different ip (but not different domains from same ip) will work once and then fail the second time as if some kind of connection bit rate cache is being used? These last two observations have not been repeated enough to be cast in stone but have been observed more than once.
I've scoured the iOS 13 release notes in hopes that I'm missing some change or need for a new key but nothing strikes me as relevant.
Any ideas appreciated!!!
A very similar question was posted earlier this year Video playback issues only on iOS 13 with AVPlayerViewController and AVPlayer when using HLS video. The unaccepted answer in that question does not apply here (and may not apply there either for all we know). I do wait for StreamPlayerItemStatusObserverContext to change to AVPlayerStatusReadyToPlay.
All the recent iPhones have 2+ microphones. Is it possible to record from all the microphones at the same time? If this is possible, what is the best iOS audio library for this (AudioKit, EzAudio, AudioUnits, CoreAudio)?
There is no mention of this functionality in AudioKit and EzAudio.
I don't see anything in the documentation about multi-mic audio capture being possible. They specify that you can choose a specific microphone but not that you can select more than one simultaneously. AVAudioSession is also a singleton.
Seemingly, at least as of iOS 10, AVCaptureSession also only allows one audio or video input concurrently.
Since, you can record stereo audio, you can definitely record from multiple microphones at once. Furthermore, since noise cancellation is likely using the 1+ microphones not participating in the stereo recording, it is likely “recording” or at least using all microphones at once.
However, I think the main crux of the questions is if we can get the audio input of each microphone separately at the same time. As Dare points out, the standard API does not support that.
However, assuming there is a one-to-one mapping from microphone source (eg top/bottom) to audio channel (left/right), a theoretical solutions exists…
Simply record in stereo, then separate out the left/right channels, and viola, you can grab the input from each microphone separately. I have not tested this out yet, but in theory it seems like it should work.
If you specifically want to know which channel corresponds to which microphone, you’ll likely need to inspect the device orientation, and have a table of where the microphones are located based on device type. For example:
if orientation == landscapeLeft && device == iPhoneX {
print(“the right audio channel source is the Face ID microphone”)
print(“the left audio channel source is the dock connector microphone”)
} …
I'm new to iOS programming and I don't know where to start. I found code examples how to read frequencies from the microphone with AudioKit framework. But this is not what I am looking for. Is it possible to retrieving frequency of the currently playing song in real time without using a microphone?
Thank you for help.
The iOS security sandbox prevents apps from capturing general audio output of any other app, such as the Music app.
Certain music apps, such as GarageBand might share inter-app audio, but this isn't supported by the majority of apps that output "songs".
An app might play the "song" itself, via an AVAudioPlayer, and tap the AVPlayer's output to get raw sample data for spectral frequency and pitch analysis (two very different things, by-the-way).
I'm working in an app where I'm able to play a HLS m3u8 playlist of a streaming radio (audio only) without any problem using an instance of AVPlayer. Using Charles I can see how the playlist is updated properly in a normal pace (each 9-10 seconds, which takes one media segment file). When I perform a seekToTime: (back in time), the player success playing the stream from when I want to, but in Charles I observe how the player starts dowloading a huge amount of media segment files, consuming a lot of data. It seems that the player downloads all the media segment files until that time and then keeps again with the normal behaviour.
I understand that the correct behaviour would be to download the media segment file for the time I'm seeking to, start playing it and then download constantly 1 or 2 media segment files each 9-10 seconds, as it does when I play the stream without timeshift.
My question is if this is a normal behaviour, or if something could be wrong with my m3u8 playlist or the client implementation. Anyone could help me to clarify this?
UPDATED: I can confirm this doesn't happen in iOS 7, so it seems to be a bug introduced by iOS 8.
I've been told by Apple that this is not a bug, but a feature. They've made the buffer bigger since iOS 8.
I'd like to stream video from the camera on an iOS device to a receiver via wifi, in effect turning the device into a wireless webcam. Is there a way to build a small app that captures video input on an iOS app and sends it via an RTSP stream or similar?
As this is an ad hoc experiment, I'm not concerned about App Store guidelines and can jailbreak if necessary.
If I interpret your question correctly you more or less need to solve four problems:
Get the camera feed.
Convert/encode this to the right format.
Stream the data.
Prevent the phone from locking itself and going into deep sleep.
The first one is fairly simple and Apple has as always provided good documentation and examples -> API link. Make sure you check out their example in the end as you will get a CMSampleBufferRef data object back.
For the second and third part, you should check out the CFNetwork framework and specially CFFTPStream for streaming using FTP.
If your are only building this for yourself then you can always turn off the Auto-Lock feature in the settings. If you on the other hand would like to distribute this to other users you could use a trick to play a mute sound every 10 seconds. This is more or less how all the alarm clocks work in the App Store. Here's a tutorial. =)
I hope I helped a little bit at least.
Good luck and best regards!
I'm 70% of the way to doing the same thing. Here's how I did it:
Capture content from video input
Chop video into files for use in HTML Live Streaming.
Spin up a web server on the iPhone and make the video files available.
Connect to the IP address of the phone and viola! you've got live streaming video.
Last time I touched the code I was trying to debug my Live Streaming not working. I'll try and get my source code posted on github this weekend, if you'd like to take a look.