I followed the top answer in this StackOverflow post to use ffmpeg-python extract a .wav file from a YouTube URL (into the pcm_s16le codec), which was played successfully by my local audio player (Mac's Music).
However, as I tried to read it using scipy.io's wavefile,
samplerate, data = wavfile.read(wav_fname)
the following error message is thrown:
"WavFileWarning: Reached EOF prematurely; finished at 1192015 bytes, expected 4294967303 bytes from header."
May anyone suggest what's going on?
I have successfully extracted a .wav file which is successfully read by my local music player. However, it is failed to be recognized by scipy.io's wavefile. And I am not sure why.
Related
My MP4 file issue is a bit complicated, so I have created a very simple scenario to help me diagnose it step by step.
I can create a working MP4 file that works flawlessly. The following is its structure shown by Mp4Explorer:
For debugging purpose, I removed the media data box mdat, and al stts, stsz,stss, stsc, stco boxes and kept everything else the same. This means the MP4 file has no media data. It just has some metadata.
This file is named error.mp4. If I run:
ffprobe "error.mp4"
I get the following error:
[mov,mp4,m4a,3gp,3g2,mj2 # 00000286e763ef00] Could not find codec parameters for stream 0 (Video: h264 (avc1 / 0x31637661), none, 1280x800): unspecified pixel format
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
Could anyone shed some light on this error? Why is it "Could not find codec parameters for stream 0"? If I remove the video track and leave the audio track as is, ffprobe will be happy with no errors.
I am using Tika server to fetch metadata and contents of various file formats. I am using server with fileUrl enabled.
When parsing .mov file which are created using quicktime screen record, it gives me the following error.
Text extraction failed (null) org.apache.tika.exception.TikaException:
Unexpected RuntimeException from
org.apache.tika.parser.mp4.MP4Parser#354bc1a2 at
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:293)
at
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
Caused by: org.mp4parser.MemoryAllocationException: Tried to allocate
1399026269 bytes, but the limit for this record type is: 536870912. If
you believe this file is not corrupt, please open a ticket on github
to increase the maximum allowable size for this record type. at
org.mp4parser.tools.MemoryUtils.allocateByteBuffer(MemoryUtils.java:30)
at org.mp4parser.support.AbstractBox.parse(AbstractBox.java:100) at
org.mp4parser.AbstractBoxParser.parseBox(AbstractBoxParser.java:115)
The size of the file is just 20Mb. Other type of .mov files with
content-type="video/quicktime"
is getting parsed with out any error. I connected the debug port and i see that it fails when converting to new IsoFile().
Any help to fix this is highly appreciated.
I start the server as shown below.
java -jar tikaserver-1.24.1.jar -enableFileUrl -enableUnsecureFeatures
I'm attempting to write an AAC file from the output stream of an AUGraph, and on playback my file only plays a buzzing noise, and I get the error ExtAudioFileWriteAsync -50.
I'd like to know what it means so that I can search for and destroy the problem.
Thanks to any Core Audio ninjas that can hook a brother up.
In case anyone else has this problem, the -50 error is a kAudio_ParamError error, defined in CoreAudioTypes.h.
Therefore, one of the parameters being passed to ExtAudioFileWriteAsync must be faulty.
I'm trying to use GDCL MP4 Muxer with my RTSP Source Filter. They work fine together except after stopping the graph, muxer doesn't finilize the file and write the reqiured tables to the end of file via file writer (some parts are written starting from moov but not the time table values). When I try another RTSP source filter (which I don't have its source codes), table values are created with GDCL MP4 Muxer.
But when I try Elecard's MP4 Muxer, it works fine with my RTSP Source Filter. So, there is an incompatibility. I examined GDCL's source codes but couldn't find what it was expecting from me. I already calculate and set timestamp values to samples using SetTime method. But GDCL still doesn't finilaze file. Is it caused by missing information or missing signal when graph stops? What can be the problem, any ideas?
One thing you should be aware of regarding Geraint's MP4 Mux is that it is checking incoming media samples to have both start and stop time. You might be having only .tStart/AM_SAMPLE_TIMEVALID which still makes sense for video, but this would be a problem.
So the samples have to have stop time, or you need to fix this in multiplexer code.
A typical symptom for the problem is that generated files are empty or of zero duration.
I'm trying to figure out the proper technique for performing skipping ahead or seeking within an mp4 (or m4a) audio file while playing it using the AudioFileStream and AudioQueue APIs on the iPhone.
If I pass the complete mp4 header (up to the mdat box) to an open AudioFileStream, the underlying audio file type is properly identified (in my case, AAC) and when I then pass the actual mdat data portion of the file, the AudioFileStream correctly begins generating audio packets and these can be sent to the AudioQueue and playback works.
However, if I try a random access approach to the playing back the file, I can't seem to get it to work properly, unless I always send the first frame of the mdat box to the AudioFileStream. If instead, after sending the mp4 header to the AudioFileStream, I then attempt to initially skip ahead to a later frame in the mdat by first calling AudioFileStreamSeek() and then passing the data for the associated packets, the AudioFileStream appears to generate audio packets, but when I pass these on to the AudioQueue and call AudioQueuePrime(), I always get an error of 'nope' returned.
My question is this: am I always required to at least pass in the first packet of the mdat box before attempting to do random playback of other packets in the mp4 file?
I can't seem to find any documentation on doing random playback of sections of an mp4 file while using an AudioFileStream and an AudioQueue. I've found Apple's QuickTime File Format pdf which describes the technique of randomly seeking within an mp4 file, but it's just a high level description and doesn't have any mention of using specific APIs (such as AudioFileStream).
Thanks for any insights.
It turns out the approach I was using with AudioFileStreamSeek() is valid, I just wasn't sending the full initial mp4 header to the AudioFileStreamParseBytes() routine.
The problem was I had assumed the packets began immediately after the mdat box tag. By examining the data offset value (kAudioFileStreamProperty_DataOffset) returned by the AudioFileStream Property Listener callback, I discovered the true start of the packet data was 18 bytes later.
These 18 bytes are considered part of the initial mp4 header that must be sent to the AudioFileStream parser before sending the data of arbitrary packets after calls to AudioFileStreamSeek().
If these extra bytes are left out, then the AudioQueuePrime() call will always fail with a 'nope' error even though you may have sent valid parsed audio packets to the AudioQueue.