[go: nahoru, domu]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Seek by audio frames #1754

Closed
4 tasks done
QuartzSTQ opened this issue Oct 20, 2023 · 3 comments
Closed
4 tasks done

Seek by audio frames #1754

QuartzSTQ opened this issue Oct 20, 2023 · 3 comments

Comments

@QuartzSTQ
Copy link
QuartzSTQ commented Oct 20, 2023

I have a lot of issues to go through, so in order to make it easier for me to help you, I ask that you please try these things first

Description

Currently if you try opening a file with just audio it seeks by 0.033 ms, which is definitely not the length of an MP3 frame for example (1152s/44.1kHz=~26 ms), and you also can't visualise where audio frames are positioned.

@mifi
Copy link
Owner
mifi commented Oct 22, 2023

Do you happen to know how to calculate mp3 sample size of a file using for example ffprobe? Not sure if it makes sense to seek by audio frames, especially for certain formats like .wav, because there's 44k samples every second so I don't know what would be the need to seek by such a small amount

@QuartzSTQ
Copy link
Author

MP3 frames are always 1152 samples, no matter what sample rate or bit rate. Other codecs are different. It would be pointless to implement for uncompressed codecs, slightly less so for losslessly-compressed codecs, since there you can just re-encode. But for splitting lossy audio this would be great since I could directly visualize where my cutting points are as opposed to using an external editor to guess and also having to figure out time differerences between them as well. Of course, for some codecs this is unnecesary anyway, for example m4acut can add gapless playback tags so exact-sample splitting is possible (as long as your player supports them as well). So I suppose being able to visualize exact samples would also be good, considering the decoder time difference problem that I mentioned.
But if there's no way to do this using ffprobe then I guess it's impossible for now.

@mifi
Copy link
Owner
mifi commented Dec 2, 2023

Ok I will hardcode frame size of 1152 and base the FPS and "short step" off that value for mp3. for aac it seems the frame size is 1024 so I will do similarily for that https://stackoverflow.com/questions/59173435/aac-packet-size

@mifi mifi closed this as completed in 9793188 Dec 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants